Re: > Re: Linux threads -- as seen in NT Magazine

[Richard Gooch]

C. S. Hendrix writes:
> 
> In message <[e-mail]>, Alan Cox writes:
> 
> > > If the thread actually sleep(2)'s on some event, fine. But most
> > > user-level threads use user-level events (i.e. pthread_cond_wait()),
> > > this ultimately resolves to a sched_yield() call, not a call to
> > > sleep().
> > 
> > That would just be crap userspace code. A good userspace lock does direct
> > CPU dependant spin locking briefly, then sched_yield a few times then
> > either backs off or drops to a semaphore lock.
> 
> This sounds rather arbitrary.  Is there a rule to follow here?

No, but reasonable heuristics.

> How do you spin lock briefly?  You mean break it on a timer?
> And do you mean to literally call sched_yield several times in a
> row?

Say spin 5 times, then loop with sched_yield() 5 times, then go to
sleep (block in kernel).
The theory is that you first spin waiting for someone else to soon
release a lock (if they're in a small critical region). Then loop with
sched_yield() to give someone else a chance (in case the locking
process is waiting for your timeslice to finish). After that, it's
probably going to take a long time (>100us) for the lock to be
released, so hop onto a wait queue.

				Regards,

					Richard....