On 7/20/07, Michael Caisse <boost@objectmodelingdesigns.com> 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