You send a signal back and do a sigwaitinfo() waiting for it. The signal
can carry a status code.
>
> > P.S.: What do you think about the cmpxchg emulation in kernel idea
> > to speed up the mutexes?
>
> I'm not sure what you mean. You can compile without the compatibility
> stuff. At least this is what is done if you configure for i686.
It still eats a function call and a switch. What I mean is to replace
pthread_mutex_lock with a inline that does:
;; ecx: mutex
movl $0,%eax ; source
movl $1,%ebx ; dest
;; selfmarker (near free if it shares the cache line with spinlock)
movl %esp, owners_stack(%ecx)
cmpxchgl %ebx, spinlock(%ecx)
bz ok
pushl %ecx ;; could even use regparm and safe this instruction
call __pthread_mutex_lock
ok:
self checks for errorcheck and recursive lock would require a range check
of the stack range now. the advantage is that is the lock is very cheap for
the uncongested case.
for the i386 case it is slower because it has to trap to the kernel, but
there is no other way [compiling for the specific cpu may be feasible for
system programs, but is not ok for the average application]. 386ers have
enough problems with threads that some small slow down [which they're
probably used to anyways because of the fp emulation..] doesn't harm too
much.
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/