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
> 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk