lkml.org 
[lkml]   [1998]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: > 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/

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.045 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site