Re: [Boost-users] [thread] Never enter critical section [NC]

From: David Daeschler (daveregs_at_[hidden])
Date: 2007-08-30 14:07:57

Hi Frederic,

> The code I gave is, in my opinion, something really common. I'm just
> wondering how other people do in such a case...

This probably doesn't help much, but we ran into the same problem when
using pthreads directly.  One thread ran while another completely
starved.  The only solution we found was to include a call to
pthread_yield after pthread_mutex_unlock in our ReleaseMutex routine.
This fixed the starvation and didn't have a huge impact on performance.

- Dave

On Thu, 2007-08-30 at 13:49 -0400, frederic.mayot_at_[hidden] wrote:
> 
> >>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. 
> 
> *************************************************************************
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users