Howard Chu wrote:
I'll note that we removed a number of the yield calls (that were in
OpenLDAP 2.2) for the 2.3 release, because I found that they were
redundant and causing unnecessary delays. My own test system is running
on a Linux 2.6.12.3 kernel (installed over a SuSE 9.2 x86_64 distro),
and OpenLDAP 2.3 runs perfectly well here, now that those redundant
calls have been removed. But I also found that I needed to add a new
yield(), to work around yet another unexpected issue on this system - we
have a number of threads waiting on a condition variable, and the thread
holding the mutex signals the var, unlocks the mutex, and then
immediately relocks it. The expectation here is that upon unlocking the
mutex, the calling thread would block while some waiting thread (that
just got signaled) would get to run. In fact what happened is that the
calling thread unlocked and relocked the mutex without allowing any of
the waiting threads to run. In this case the only solution was to insert
a yield() after the mutex_unlock(). So again, for those of you claiming
"oh, all you need to do is use a condition variable or any of the other
POSIX synchronization primitives" - yes, that's a nice theory, but
reality says otherwise.
I encountered a similar issue with some software that I wrote, and used
a similar workaround, however this was basically because there wasn't
enough time available at the time to redesign things to work properly.
The problem here is essentially caused by the fact that the mutex is
being locked for an excessively large proportion of the time and not
letting other threads in. In the case I am thinking of, posting the
messages to the thread that was hogging the mutex via a signaling queue
would have been a better solution than using yield and having correct
operation depend on undefined parts of thread scheduling behavior..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|