Re: [boost] Copyable mutex

From: Phillip Hellewell (sshock_at_[hidden])
Date: 2007-07-20 17:59:15

On 7/20/07, Michael Caisse <boost_at_[hidden]> wrote:
>
> assignment semantics for the class. Copying or assigning objects with
> multithreaded
> concepts is almost never as easy as the default... and if it is, I like to
> see a comment
> saying so and why.
>

Agreed.  In fact, I was just thinking how grateful I am that many of my
classes are non-copyable, non-assignable, and read-only (e.g., all functions
are const).  That makes it pretty easy to make them thread-safe.  I just use
shared pointers to "copy" them around.

Some of my classes are non-copyable and non-assignable, but may change after
being constructed.  These aren't too hard to make thread-safe, e.g., by
synchronizing the functions that make changes.

Making a copyable class thread-safe isn't too bad either.  For example, you
can synchronize the copy ctor using the rhs's mutex(es).  This should
prevent getting an inconsistent copy.

However, even the simplest _assignable_ class seems almost impossible to me
to make thread-safe.  You can synchronize operator= using both its own
mutex(es) and rhs's mutex(es), which seems to solve the problem.  But how do
you prevent deadlock from something like this?

Thread 1: x = y
Thread 2: y = x

Thread 2 is going to lock the mutexes in the opposite order of thread 1.
Ouch!

Oh well, not all my classes need to be thread-safe :)  I'll just put a
little comment here...

Phillip