Boost logo

Boost :

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.

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at