From: frederic.mayot_at_[hidden]
Date: 2007-08-30 13:49:15
>>On Thu, Aug 30, 2007 at 12:08:51PM -0400, frederic.mayot_at_[hidden]
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.
*************************************************************************