On Mon, Jul 19, 2010 at 9:11 AM, Jan Stoess <sto...@kit.edu> wrote: >> On OKL4, there's a kernel-supported mutex_t object in their lib, >> but I see nothing similar in L4Ka::Pistachio; neither in the spec, >> nor in the source of kernel and user. > > You're right, pistachio doesn't offer a kernel-supported > mutex/locking scheme at the moment.
I guess it's not strictly needed. However, a little help from the kernel could be useful to improve efficiency (s. below). >> If the kernel doesn't provide mutexes, they have to be implemented >> in user space, right? I'm thinking of something like a dedicated >> 'mutex' manager thread per task, that other threads would [L]IPC to >> lock and unlock mutexes. Does that make sense, or am I completely >> lost here? > > Sounds sensible. But I'm also sure OKL4 has a reason to offer a > kernel primitive. My guess is that it is because kernel notifications > are convenient and can be better integrated into the scheduler and/or > other kernel subsystems. But I personally have never looked into the > details, so it might make sense to ask the OKL4 developers directly. Perhaps OKL4 provides a kernel primitive for efficiency reasons, but it's not strictly needed? If we look at a typical mutex implementation, e.g. on Solaris or NetBSD [1,2,3], there are two kinds of mutexes: spin mutexes and adaptive mutexes. An adaptive mutex is like a normal blocking mutex, which first checks if the mutex owner thread is currently running (on another CPU?) and if so, it would spin, else it would block. The rationale being, that mutexes owned by running threads are usually held for a very short time period (a few instructions), so spinning makes more sense than blocking and incurring a context switch + long waiting to be reawakened. Blocking should only happen if the mutex owner is itself sleeping. Now, the algorithm for the spinning loop requires frequent checking of the *other* (mutex owner) thread's status (is it running, stopped, etc...?). If we have to repeatedly use the SCHEDULE syscall to get that status, that could be quite slow. Maybe that's one reason for a kernel primitive? Direct access to the other threads status? If so, couldn't that status be exported read-only to all threads, so calls to SCHEDULE would be bypassed? The other reason for a kernel primitive may be to prevent the spinning thread from being interrupted by raising the interrupt level (?), but I admit that I'm still rather confused on this point. So it all boils down to: what's the best way to port those mutexes to Pistachio, either in user space or as a kernel primitive? ;-) [1] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/mutex.h?rev=1.19.2.1&content-type=text/x-cvsweb-markup [2] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/kern_mutex.c?rev=1.48.2.1&content-type=text/x-cvsweb-markup [3] http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/amd64/amd64/lock_stubs.S?rev=1.20.6.1.2.2.2.1&content-type=text/x-cvsweb-markup Thanks, -Farid. > Best, > -Jan > > -- > Dr.-Ing. Jan Stoess > KIT/UKa System Architecture Group > Phone: +49 (721) 608 4056 > Fax: +49 (721) 608 7664 > http://os.ibds.kit.edu/stoess
