Linked by nfeske on Thu 23rd Aug 2012 08:30 UTC
Permalink for comment 532243
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
More News »
Sponsored Links



Member since:
2011-01-28
nfeske,

Like you, I'd have to research it more. But I think an excellent test would be a database engine that doesn't use memory mapped IO. I think mysql is such a database, particularly because 32bit addressing is an unacceptable limitation. Not sure how it works in 64 bit though.
http://doc.51windows.net/mysql/?url=/MySQL/ch07s05.html
"Only compressed MyISAM tables are memory mapped. This is because the 32-bit memory space of 4GB is not large enough for most big tables. When systems with a 64-bit address space become more common, we may add general support for memory mapping."
When you implement a pread in libc, does it look something like this?
(Apologies in advance for the spacing bugs...Thom get that fixed!!)
int pread(...) {
aquire_process_mutex(...);
long long pos = lseek(...);
int ret = read(...);
lseek(pos); // since pread isn't supposed to have side effects
free_mutex(...);
return ret;
}
This makes 3 calls to the file system, do those functions have their own internal mutexes such that each pread/pwrite call will actually invoke 4 total mutex cycles (instead of 1 needed by a native pread function)? That would be alot of sync overhead on SMP systems (IMHO).
Also, I think the following example might be able to break the above atomicity:
void uncertainty() {
char data;
int handle = open(...,O_WRONLY|O_TRUNC);
int pid = fork();
if (pid==0) {
data=1;
pwrite(handle, &data, sizeof(data), 1)
} else {
data=2
pwrite(handle, &data, sizeof(data), 1);
waitpid(pid);
}
}
We would normally expect only 2 possible arbitrary outcomes:
0x00 0x01 # child overwrote parent
0x00 0x02 # parent overwrote child
However due to race conditions on lseek, we might end up with these variances as well.
0x02 0x01
0x01 0x02
Granted this example is contrived. I don't know if there are typical applications that share file descriptors between processes and use pread/pwrite on them?
I brought this up because I really enjoy technical analysis, not because of any particular concern. But if I'm bugging you too much feel free to tell me to sod off