Re: Simple copy-on-write framework
Ulrich Eckhardt wrote:
Joe Seigh wrote:
Ulrich Eckhardt wrote:
I recently stumbled over the fact that using existing tools it is
quite easy to create a COW framework (almost) without any
additional locking for multithreaded code.
The idea is simple:
1. While you modify an object, you store it in a std::auto_ptr<T>. This
makes sharing the object impossible (due to auto_ptr's move semantics).
2. If you want to share an object, you store it in a
boost::shared_ptr<T
const>.
[...]
Quite simple and charming, so I thought I'd share it. And also of
course to get some peer review.
You probably get not a few comments to check out String implementations
that use COW with reference counting.
IIRC, COW std::strings mostly suffer from the fact that operator[] returns
a mutable C++ reference which is obviously totally ignorant of the COW
schemes behind it, so making it provably correct requires more copying
than it usually would.
Not just that it requires more copying. It requires blocking
copying in functions (like the copy constructor) which would
normally do it, if a mutator object has ever been made; in other
terms, it requires additional state, and there are hard limits
to the amount of state you can atomically modify without
locking.
Or is it even impossible considering the required
interface?
It's not even difficult. It just requires locking in every
access. Sun has a 100% working version.
Of course, the results are so slow as to make it unusable, but
it is correct, and 100% standard conformant.
I don't remember.
However, my idea is rather geared to a Java-like design (I think, I'm
rather ignorant of Java otherwise) where you have immutable strings and,
when you need to modify one, a stringbuffer. Java of course uses GC
instead of refcounting, but that shouldn't make a difference.
No. the difference is that StringBuffer's don't share
representation, either among themselves or with String's. (This
isn't quite true, and there are cases where String's share the
representation with a StringBuffer. But always a single
StringBuffer, who is the only possible modifier. And the
StringBuffer notes when it has leaked the buffer, and makes a
deep copy immediately in every non-const function.)
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]