Boost logo

Boost Users :

From: David Daeschler (daveregs_at_[hidden])
Date: 2007-08-30 15:54:29


> Does someone understand the rationale for this implementation?

The rationale for the implementation is that the second thread wasn't
given the opportunity to acquire the mutex because pthread_lock/unlock
doesn't guarantee that the first thread won't just grab it again. We
needed a way to prevent this, as it was happening every time.

Summed up pretty well here, it seems like it's up to the OS scheduler
and the scheduling policy who gets the mutex:

http://www.redhat.com/archives/phil-list/2004-February/msg00027.html
(that entire thread is pretty interesting)

Linux behaved in a different manner than other OSs we had compiled on.
It kept giving the mutex to the first thread every time (which looks to
be an acceptable behavior). pthread_yield() allowed the component to
work properly under Linux until we had more time to figure out what was
happening. Yielding the remainder of the time slice must have given the
second thread enough time to acquire the mutex.

We ended up restructuring the code to prevent the problem in the future,
but this may not be an option for everyone.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net