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

[Andrei Alexandrescu via Digitalmars-d]

On 9/15/14, 9:56 AM, Rainer Schuetze wrote:
> 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!?

The conversion relies on pure constructors. As I noted in the opening 
post, I also think there's something too lax in there. If you have a 
reduced example that shows a type system breakage without cast, please 
submit.

>>> * 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.

I'm not sure about that discussion, but there's good evidence from C++ 
that refcounting with atomics works. What was the smoking gun?


Andrei