[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#3950) sched_yield() considered harmful
Howard Chu wrote:
>> If OpenLDAP must remain compatible with OSes where pthreads aren't
>> available, locking can be abstracted in portability functions like
>> sched_yield() was.
>
> This is not an issue of OpenLDAP compatibility, or OSes which do or
> don't support pthreads. sched_yield()
> is a standard feature of pthreads. It is neither optional nor
> "non-portable" and is used heavily in more software than just OpenLDAP.
> If the current Linux kernel hackers want to convince all the application
> developers out there to rewrite their software for the 2.6 kernel's
> benefit that's certainly their prerogative, but they should not be
> surprised if this decision is met with resistance.
I, too, consider the old behavior of sched_yield() in 2.4
a better approximation of my personal idea of how yielding
the CPU should be handled by a scheduler with dynamic and
static priorities.
However, the kernel hackers appear to think otherwise:
http://marc.theaimsgroup.com/?l=linux-kernel&m=112433402319824&w=4
I don't know what leads to this conclusion, but at least
it seems it's done deliberately and not by mistake. I'll
ask out of curiosity.
Regardless, a threaded server application such as slapd
shouldn't ever need to call sched_yield(). The pthreads
API provides plenty of synchronization primitives that don't
require low-level tweaking of scheduling behavior and are
therefore more portable and usually more efficient.
Disclaimer: I know very little about slapd internals,
so I may well have overseen something...
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/