lkml.org 
[lkml]   [2005]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sched_yield() makes OpenLDAP slow
Nikita Danilov wrote:
> Howard Chu writes:
>
> > That's beside the point. Folks are making an assertion that
> > sched_yield() is meaningless; this example demonstrates that there are
> > cases where sched_yield() is essential.
>
> It is not essential, it is non-portable.
>
> Code you described is based on non-portable "expectations" about thread
> scheduling. Linux implementation of pthreads fails to satisfy
> them. Perfectly reasonable. Code is then "fixed" by adding sched_yield()
> calls and introducing more non-portable assumptions. Again, there is no
> guarantee this would work on any compliant implementation.
>
> While "intuitive" semantics of sched_yield() is to yield CPU and to give
> other runnable threads their chance to run, this is _not_ what standard
> prescribes (for non-RT threads).
>
Very well; it is not prescribed in the standard and it is non-portable.
Our code is broken and we will fix it.

But even Dave Butenhof, Mr. Pthreads himself, has said it is reasonable
to expect sched_yield to yield the CPU. That's what pthread_yield did in
Pthreads Draft 4 (DCE threads) and it is common knowledge that
sched_yield is a direct replacement for pthread_yield; i.e.,
pthread_yield() was deleted from the spec because sched_yield fulfilled
its purpose. Now you're saying "well, technically, sched_yield doesn't
have to do anything at all" and the letter of the spec supports your
position, but anybody who's been programming with pthreads since the DCE
days "knows" that is not the original intention. I wonder that nobody
has decided to raise this issue with the IEEE/POSIX group and get them
to issue a correction/clarification in all this time, since the absence
of specification here really impairs the usefulness of the spec.

Likewise the fact that sched_yield() can now cause the current process
to be queued behind other processes seems suspect, unless we know for
sure that the threads are running with PTHREAD_SCOPE_SYSTEM. (I haven't
checked to see if PTHREAD_SCOPE_PROCESS is still supported in NPTL.)

--
-- 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 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/

\
 
 \ /
  Last update: 2005-08-23 00:29    [W:0.058 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site