Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Peter Dimov (pdimov_at_[hidden])
Date: 2011-03-07 11:43:53

Chad Nelson wrote:

> On Mon, 7 Mar 2011 03:01:51 +0200
> "Peter Dimov" <pdimov_at_[hidden]> 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.