>>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.
*************************************************************************