Boost logo

Boost Users :

Subject: Re: [Boost-users] boost::recursive_mutex doesn't lock ???
From: Chris (cmrchs_at_[hidden])
Date: 2010-11-03 06:07:07


Hello Marsh.

thank you for your reply.

>Yep, that's what the 'recursive' means: the same thread is allowed to re-acquire the lock multiple times.
I see what you mean

>but why would you want a thread to block in the usual case?
well, I start a main thread up to a certain point but don't want to
continue until 2 other threads have finished executing some Init
statements

Code sample:

boost::recursive_mutex rec_mutex;

void F1()
{
        cout << "F1: perform init... \n";
        // decrease recursion_count
        rec_mutex.unlock();
        // ... continue here
} // F1()

void F2()
{
        cout << "F2: perform some other init... \n";
        // decrease recursion_count
        rec_mutex.unlock();
        // ... continue here
} // F2()

int main()
{
        // lock twice
        rec_mutex.lock();
        rec_mutex.lock();

        // start both htreads
        boost::thread thrd1(&F1);
        boost::thread thrd2(&F2);

        // wait for both thread to finish their Init-part
        boost::recursive_mutex::scoped_lock lock(rec_mutex);

        // ... continue here
}

but the main thread doesn't stop at
boost::recursive_mutex::scoped_lock lock(io_mutex);

How should I implement it then? not using recursive_mutex?

thank you
Chris

On Nov 2, 9:22 pm, Marsh Ray <ma..._at_[hidden]> wrote:
> On 11/02/2010 02:33 PM, Chris wrote:
>
>
>
>
>
> > So far no problem, but if I use recursive_mutex instead...
>
> > Scenario 2: (NOT OK)
>
> >    int main()
> >    {
> >            boost::recursive_mutex  io_mutex;
> >            io_mutex.lock();
>
> >            // thread will NOT be blocked   ???
> >            boost::recursive_mutex::scoped_lock lock(io_mutex);
> >            cout<<  "Test"          // this statement is executed  ???
> >    }
>
> > no blocking occurs??
>
> Yep, that's what the 'recursive' means: the same thread is allowed to
> re-acquire the lock multiple times. After all, if this thread already
> has acquired a lock on the mutex it's basically a no-op. The resource is
> protected from concurrent access.
>
> If a thread blocks on a non-recursive mutex that it's already locked,
> wouldn't it be a guaranteed deadlock?
>
> Some code might have its reasons, but why would you want a thread to
> block in the usual case?
>
> Just depends on what kind of mutexes you're more familiar with I guess.
>
> > How does one lock a recursive_mutex then?
>
> If you want to observe something blocking, create another thread.
>
> - Marsh
> _______________________________________________
> Boost-users mailing list
> Boost-us..._at_[hidden]http://lists.boost.org/mailman/listinfo.cgi/boost-users


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