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 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...@lists.boost.orghttp://lists.boost.org/mailman/listinfo.cgi/boost-users

Hi Chris, Chris wrote:

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 [snip] How should I implement it then? not using recursive_mutex?

That sounds like a sync barrier will fit much better here. http://boost.org/doc/libs/1_44_0/doc/html/thread/synchronization.html#thread... Christopher.