Chad Nelson wrote:
On Mon, 7 Mar 2011 03:01:51 +0200 "Peter Dimov" <pdimov@pdimov.com> wrote:
The only concrete complaint that people could give me about CoW was that code using it couldn't be made thread-safe, which is true.
Can you please provide more details? Why is not CoW thread safe?
Because the copy-on-write functionality is entirely internal to the class. Nothing outside it can tell whether it's safe to modify an integer or not, in the presence of multithreading. Even the library itself can't tell unless I add locking for each integer object, which would slow things down and introduce a compiled dependency for little benefit.
Unless you allow non-const references or iterators to your shared data, code outside can't modify it without you being aware of it, and CoW is transparent (assuming atomic reference counting). You only need your integers to be "as thread safe as an int" (or, equivalently, as a deep copy integer). This means that: (1) in a function that reads an integer instance you can assume that no other thread writes it; (2) in a function that writes an integer instance you can assume that no other thread reads or writes it; (3) in a function that writes an integer no other thread reads the data, because you've just made the data unique, and for it to become non-unique another thread must copy the instance, see (1) (4) in a function that reads an integer no other thread writes the data, for similar reasons.