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
