Re: (ITS#3950) sched_yield() considered harmful

[bernie@develer.com]

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/