|
From: Julian S. <js...@ac...> - 2012-02-15 08:59:48
|
On Wednesday, February 15, 2012, Tom Hughes wrote: > On 15/02/12 07:22, Bart Van Assche wrote: > > Note: glibc mutexes do a little more than invoking the futex syscalls > > directly - if I remember correctly the pthread_mutex_lock() > > implementation first spins for a short time in order to minimize the > > number of system calls invoked. > > That's the whole point of the futex - you only have to make a system > call and enter the kernel when the lock is contended. > > I don't think it actually spins in userspace, it's just that it is able > to check (and if available take) the lock from userspace and only enter > the kernel if it needs to block. For sure we will need to have our own library of locking primitives. The non-contended case, using atomic memory operations, is easy enough (for some definition of easy. Drepper's "Futexes are tricky" shows how hairy even that part can be). The tricky bit IMO is going to be the contended case. On Linux we can fall back to futexes in the normal way, but on Darwin I imagine the kernel-level helpers for contended cases are completely different. And may even be different in different OSX versions. I'm sure I saw a bunch more threading-sounding syscalls for 10.7 that weren't present in 10.6. J |