Re: sched_yield() makes OpenLDAP slow

[Helge Hafting <helge.hafting@aitel.hist.no>]

David Schwartz wrote:

> > Robert Hancock wrote:
> >    
> >
> > But the thread the released the
> > mutex is not one of the waiting threads, and is not eligible for
> > consideration.
> >    
>
> 	Where are you getting this from? Nothing requires the scheduler to schedule
> any threads when the mutex is released.
>  
Correct.

> 	All that must happen is that the mutex must be unlocked. The scheduler is
> permitted to allow any thread it wants to run at that point, or no thread.
> Nothing says the thread that released the mutex can't continue running and
>  
Correct. The releasing thread may keep running.

> nothing says that it can't call pthread_mutex_lock and re-acquire the mutex
> before any other thread gets around to getting it.
>  
Wrong.
The spec says that the mutex must be given to a waiter (if any) at the
moment of release.  The waiter don't have to be scheduled at that
point, it may keep sleeping with its freshly unlocked mutex.  So the
unlocking thread may continue - but if it tries to reaquire the mutex
it will find the mutex taken and go to sleep at that point. Then other
processes will schedule, and at some time the one now owning the mutex
will wake up and do its work.

> 	In general, it is very bad karma for the scheduler to stop a thread before
> its timeslice is up if it doesn't have to. Consider one CPU and two threads,
> each needing to do 100 quick lock/unlock cycles. Why force 200 context
> switches?
Good point, except it is a strange program that do this.  Lock the mutex 
once,
do 100 operations, then unlock is the better way. :-)

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/