lkml.org 
[lkml]   [2004]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectFutex wake behavior question
Date
(2nd try at posting this.  from different email acct this time)

I have a question about futex wake behavior. On a uniprocessor is
it supposed to preempt the caller and dispatch the woken thread if
all threads in question have equal priority?

I was playing around with an experimental lock-free implementation
of condvars (no internal lock) and I got a 30% performance improvement
over NPTL's implementation which I didn't expect since the mutex the
condvar is bound to tends to be the gating factor. I did getrusage()
to get some stats and noticed the context switching was proportional
to the condvar signaling, the difference between the NPTL and lock-free
versions being one context switch which I attribute to NPTL's internal
mutex.

As a side note, since wait morphing doesn't appear to be currently
implemented in NPTL, you get a performance boost from signaling while
not holding the mutex since the first thing the woken thread does is
try to get the lock. Even with this technique, the lock-free condvar
does better.

This behavior would also cause problems for semaphores and tend to turn
semaphore calls into expensive coroutine calls.

So the question is, is this a feature or a bug? I'm on Suse 9.2 on
a uniprocessor. The kernel is 2.6.8-24 and NPTL is 2.3.3.


Joe Seigh

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

-
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-03-22 14:07    [W:0.042 / U:1.368 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site