Messages in this thread | | | Date | Sun, 18 Jul 1999 20:21:02 +0200 | From | Andi Kleen <> | Subject | Re: kernel thread support - LWP's |
| |
On Sun, Jul 18, 1999 at 10:38:11AM -0700, Ulrich Drepper wrote: > Andi Kleen <ak@muc.de> writes: > > > Manager checks thr->setuperr after waitpid(). > > The thread itself never runs when it fails. > > *When* does the manager checks for it? The clone might not have > executed a single instruction when the clone() function returns. And I > don't want to add a mutex etc in there which means lots of more > syscalls and context switches.
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/
| |