lkml.org 
[lkml]   [2005]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectre: sched_yield() makes OpenLDAP slow
Hm, seems there's a great deal of misinformation in this thread.

> I also think OpenLDAP is wrong. First, it should be calling
> pthread_yield() because slapd is a multithreading process and it just
> wants to run the other threads. See:
...
> AFAIKS, sched_yield should only really be used by realtime
> applications that know exactly what they're doing.

pthread_yield() was deleted from the POSIX threads drafts years ago.
sched_yield() is the officially supported API, and OpenLDAP is using it
for the documented purpose. Anyone who says "applications shouldn't be
using sched_yield()" doesn't know what they're talking about.

> It's really more a feature than a bug that it breaks so easily
> because they should be really using futexes instead, which have much
> better behaviour than any sched_yield ever could (they will directly
> wake up another process waiting for the lock and avoid the thundering
> herd for contended locks)

You assume that spinlocks are the only reason a developer may want to
yield the processor. This assumption is unfounded. Case in point - the
primary backend in OpenLDAP uses a transactional database with
page-level locking of its data structures to provide high levels of
concurrency. It is the nature of such a system to encounter deadlocks
over the normal course of operations. When a deadlock is detected, some
thread must be chosen (by one of a variety of algorithms) to abort its
transaction, in order to allow other operations to proceed to
completion. In this situation, the chosen thread must get control of the
CPU long enough to clean itself up, and then it must yield the CPU in
order to allow any other competing threads to complete their
transaction. The thread with the aborted transaction relinquishes all of
its locks and then waits to get another shot at the CPU to try
everything over again. Again, this is all fundamental to the nature of
transactional programming. If the 2.6 kernel makes this programming
model unreasonably slow, then quite simply this kernel is not viable as
a database platform.

--
-- 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-19 08:06    [W:0.048 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site