Messages in this thread | | | Date | Wed, 16 Dec 1998 12:02:33 +1100 | From | Richard Gooch <> | Subject | Re: > Re: Linux threads -- as seen in NT Magazine |
| |
C. S. Hendrix writes: > > In message <m0zpyLT-0007U1C@the-village.bc.nu>, 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....
- 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/
| |