Linked by nfeske on Thu 23rd Aug 2012 08:30 UTC
OSNews, Generic OSes The just released version 12.08 of the Genode OS Framework comes with the ability to run Genode-based systems on ARM hardware without an underlying kernel, vastly improves the support for the NOVA hypervisor, and adds device drivers for the OMAP4 SoC. Further functional additions are a FFAT-based file system service, the port of the lighttpd web server, and support for on-target debugging via GDB.
Permalink for comment 532243
To read all comments associated with this story, please click here.
RE[4]: Good Progress
by Alfman on Sat 25th Aug 2012 14:37 UTC in reply to "RE[3]: Good Progress"
Alfman
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 ;)

Reply Parent Score: 2