On 15.09.2014 09:22, Andrei Alexandrescu wrote:
On 9/15/14, 8:58 AM, Rainer Schuetze wrote:
On 15.09.2014 07:49, Andrei Alexandrescu wrote:
I haven't found a single lock, is single threading by design or is
thread-safety on your todo?
Currently shared strings are not addressed.
Please also consider usage with const and immutable:
* both will disallow changing the reference count without casting
I think these work fine. If not, please send examples.
Hmm, seems fine when I try it. It feels like a bug in the type system,
though: when you make a copy of const(RCXString) to some RCXString, it
removes the const from the referenced RCBuffer struct mbuf!?
* immutable means implicitely shared between threads, so you'll have to
make RCString thread-safe even if shared isn't explicitly supported.
Hmmm, good point. That's a bug. Immutable postblit and dtors should use
atomic ops.
Unfortunately, I've yet to see an efficient thread-safe implementation
of reference counting (i.e. without locks).
No locks needed, just interlocked ++/--.
Eager reference counting with atomics is not thread safe. See the
discussions about automatic reference counting.
VC used to have reference counted strings, but moved away from it. Maybe
it doesn't pull its own weight in the face of the
small-string-optimization.
The reason of C++ strings moving away from refcounting is not strongly
related to interlocked refcounting being slow.
Yes, they did not care for thread safety back then. IIRC they had no
small-buffer-optimization. With that, reference counting only kicks in
with large strings.
If we need a lock on these for proper reference counting, it's still
better than making a copy including a global lock by the allocator.
Rainer
