|
Boost : |
From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-05-31 10:46:38
Hmm .... you know that COW implementations of strings tend not to be
thread-safe, or if they are thread-safe, deadly slow?
For example DinkumWare switched from a COW implementation of strings to a
small string optimization in the 7.1 release of VC. We run a million-plus
transactions through our system every day, and monitor every crash. We've
observed two things from this change:
- crashes due to accidently passing strings between threads have
disappeared.
- speed has not changed detectably. In fact, if anything, seems to have
increased slightly.
So, I'd never use a COW implementation again in a multithreaded
environment - it's just simply impossible to make thread safe.
"Maksym Motornyy" <mmotorny_at_[hidden]> wrote in message
news:d7hvcu$usf$1_at_sea.gmane.org...
> > There's a pretty nice implementation of COW objects in the Adobe Open
> > Source library (http://opensource.adobe.com). You might take a look
> > at that.
> I saw it. Honestly, after I implemented COW myself :) Do you want to say
> it's no sence to double existing things?
>
> > A compiler
> > that implements NRVO (Named Return Value Optimization) can return an
> > object (essentially) by const reference without any special COW
> > wrapper classes.
> Agree, this is not the best example for such a compiler. AFAIK VC++
> doesn't implement this optimization.
>
> > Also, some C++ Standard Library implementations use
> > a reference-counted std::string implementation, so this extra effort
> > would be wasted.
> STLport and Dinkumware (I suppose most widely used) doesn't belong to
> that implementations. That's why personally I require COW-wrapper.
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk