On Thu, Aug 30, 2007 at 12:08:51PM -0400, frederic.mayot@sgcib.com wrote: Hi, I'm having a problem with mutexes.
In one thread T1 I have: while(!end) { /* TTT */ lock lk(mutex); dosomethingquick(); }
I'm sure dosomethingquick returns but T2 can never acquires the mutex. If I had a timer on line /* TTT */ in T1 (sleeps for a millisecond), everything works fine.
Can anyone understand such a behavior? Am I doing something wrong here?
A guess: T1 reacquires the mutex before the OS actually dispatches T2 to run. Unlocking the mutex just makes "ready" one of threads waiting for it, but I'm not sure that it's required that the thread be immediately dispatched it onto (a) CPU. When you insert a volountary sleep in T1, the scheduler puts T1 to sleep and chooses another ready thread (T2 in this case) to run.
Oh yes, I know that. The thing is I don't know what to do. The code I gave is, in my opinion, something really common. I'm just wondering how other people do in such a case... It seems completely absurd that I would have to add a sleep just to help a thread acquiring a mutex!! The NPTL does not offer fair mutexes (hence, neither boost). Leaving my code as is, the only workaround I see would be to use an atomic variable v. T2 sets v to true at the beginning of f() and sets it back to false at the end. T1 would sleep only if the variable is true. What an ugly patch!! ************************************************************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. *************************************************************************