Re: sched_yield() makes OpenLDAP slow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Robert Hancock wrote:
> Howard Chu wrote:
> > POSIX requires a reschedule to occur, as noted here:
> > http://blog.firetree.net/2005/06/22/thread-yield-after-mutex-unlock/
>
> No, it doesn't:
>
> >
> > The relevant SUSv3 text is here
> > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_unlock.html
>
> "If there are threads blocked on the mutex object referenced by mutex
> when pthread_mutex_unlock() is called, resulting in the mutex becoming
> available, the scheduling policy shall determine which thread shall
> acquire the mutex."
>
> This says nothing about requiring a reschedule. The "scheduling policy"
> can well decide that the thread which just released the mutex can
> re-acquire it.

No, because the thread that just released the mutex is obviously not one of the threads blocked on the mutex. When a mutex is unlocked, one of the *waiting* threads at the time of the unlock must acquire it, and the scheduling policy can determine that. But the thread the released the mutex is not one of the waiting threads, and is not eligible for consideration.

> > I suppose if pthread_mutex_unlock() actually behaved correctly we could
> > remove the other sched_yield() hacks that didn't belong there in the
> > first place and go on our merry way.
>
> Generally, needing to implement hacks like this is a sign that there are
> problems with the synchronization design of the code (like a mutex which
> has excessive contention). Programs should not rely on the scheduling
> behavior of the kernel for proper operation when that behavior is not
> defined.
>
> --
> Robert Hancock      Saskatoon, SK, Canada
> To email, remove "nospam" from [email protected]
> Home Page: http://www.roberthancock.com/

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux