Escaping the Tyranny of the GC: std.rcstring, first blood

[Rainer Schuetze via Digitalmars-d]

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