On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
wrote:
>
> The road there is long, but it starts with the proverbial first step. As it were, I have a rough draft of a almost-drop-in replacement of string (aka immutable(char)[]). Destroy with maximum prejudice:
>
> http://dpaste.dzfl.pl/817283c163f5

So slicing an RCString doesn't increment its refcount?

On Monday, 15 September 2014 at 12:47:08 UTC, Robert burner
Schadek wrote:
> On Monday, 15 September 2014 at 12:11:14 UTC, Jakob Ovrum wrote:
>>>> There's no use of `shared`, so all data involved is TLS.
>>>
>>> Then it must be made sure that send and receive work properly.
>>
>> They do. They only accept shared or immutable arguments (or
>> arguments with no mutable indirection).
>
> compiler says no: concurrency.d(554): Error: static assert  "Aliases to mutable thread-local data not allowed."
>
> I used the std.concurrency example

Probably because RCString is only logically immutable--it
contains unions of mutable and immutable members to simplify
construction.

On Monday, 15 September 2014 at 16:22:01 UTC, Andrei Alexandrescu
wrote:
> On 9/15/14, 8:58 AM, Rainer Schuetze wrote:
>
>> * 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 ++/--.

To be fair, you still have to be a bit careful here or things
could be optimized such that data is seen to disappear or change
when it's not expected to.  The original boost::shared_ptr used
an atomic integer as an internal refcount, and that's probably a
good template for how to do RC here.  The newer implementation is
a lot fancier with spinlocks and such, I believe, and is a lot
more complicated.

Also... this is why I'm not over-fond of having immutable being
implicitly shared.  Being unable to create an efficient RCString
that I know is thread-local (the normal case) kind of stinks.  Maybe there can be a
template parameter option along these lines?

On Monday, 15 September 2014 at 03:52:34 UTC, Andrei Alexandrescu wrote:
> We're thinking of a number of schemes for reference counted objects, and we think a bottom-up approach to design would work well here: try a simple design and assess its limitations. In this case, it would be great if you tried to use RefCounted with your class objects and figure out what its limitations are.

RefCounted currently does not work at all with class objects. This is explicitly indicated in RefCounted's template constraint.

Are you saying we should try to make RefCounted work with classes or something else?

On Monday, 15 September 2014 at 18:08:31 UTC, po wrote:
>
>>> I'm not sure about that discussion, but there's good evidence from C++ that refcounting with atomics works. What was the smoking gun?
>>
>> http://www.gotw.ca/gotw/045.htm
>
>  I don't see how that link answers Andrei's question? He just compares different methods of implementing COW.

As I understand the issue it works if you make sure to transfer ownership explicitly before the other thread gains access?

Maybe this is more clear:

http://www.1024cores.net/home/lock-free-algorithms/object-life-time-management/differential-reference-counting

On 9/15/14, 11:21 AM, Sean Kelly wrote:
> On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
> wrote:
>>
>> The road there is long, but it starts with the proverbial first step.
>> As it were, I have a rough draft of a almost-drop-in replacement of
>> string (aka immutable(char)[]). Destroy with maximum prejudice:
>>
>> http://dpaste.dzfl.pl/817283c163f5
>
> So slicing an RCString doesn't increment its refcount?

It does. -- Andrei

On 9/15/14, 11:28 AM, Sean Kelly wrote:
> On Monday, 15 September 2014 at 16:22:01 UTC, Andrei Alexandrescu
> wrote:
>> On 9/15/14, 8:58 AM, Rainer Schuetze wrote:
>>
>>> * 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 ++/--.
>
> To be fair, you still have to be a bit careful here or things
> could be optimized such that data is seen to disappear or change
> when it's not expected to.  The original boost::shared_ptr used
> an atomic integer as an internal refcount, and that's probably a
> good template for how to do RC here.  The newer implementation is
> a lot fancier with spinlocks and such, I believe, and is a lot
> more complicated.

That's news to me. Perhaps it's weak pointer management they need to address?

> Also... this is why I'm not over-fond of having immutable being
> implicitly shared.  Being unable to create an efficient RCString
> that I know is thread-local (the normal case) kind of stinks. Maybe
> there can be a
> template parameter option along these lines?

Non-immutable and non-shared RCStrings are the ticket.


Andrei

On Monday, 15 September 2014 at 18:39:09 UTC, Andrei Alexandrescu
wrote:
> On 9/15/14, 11:21 AM, Sean Kelly wrote:
>> On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu
>> wrote:
>>>
>>> The road there is long, but it starts with the proverbial first step.
>>> As it were, I have a rough draft of a almost-drop-in replacement of
>>> string (aka immutable(char)[]). Destroy with maximum prejudice:
>>>
>>> http://dpaste.dzfl.pl/817283c163f5
>>
>> So slicing an RCString doesn't increment its refcount?
>
> It does. -- Andrei

Oops, I was looking at the opSlice for Large, not RCString.

On 9/15/14, 11:30 AM, Vladimir Panteleev wrote:
> On Monday, 15 September 2014 at 03:52:34 UTC, Andrei Alexandrescu wrote:
>> We're thinking of a number of schemes for reference counted objects,
>> and we think a bottom-up approach to design would work well here: try
>> a simple design and assess its limitations. In this case, it would be
>> great if you tried to use RefCounted with your class objects and
>> figure out what its limitations are.
>
> RefCounted currently does not work at all with class objects. This is
> explicitly indicated in RefCounted's template constraint.
>
> Are you saying we should try to make RefCounted work with classes or
> something else?

Yes, we should define RefCounted for classes as well. (Sorry, I was confused.) Extending to class types should be immediate at least in the first approximation. Then we can stand back and take a look at the advantages and liabilities.

Could someone please initiate that work?


Thanks,

Andrei

Am Mon, 15 Sep 2014 15:34:53 +0000
schrieb "Jakob Ovrum" <jakobovrum@gmail.com>:

> On Monday, 15 September 2014 at 02:26:19 UTC, Andrei Alexandrescu wrote:
> > http://dpaste.dzfl.pl/817283c163f5
> 
> The test on line 267 fails on a 32-bit build:
> 
> rcstring.d(267): Error: cannot implicitly convert expression (38430716820228232L) of type long to uint

https://issues.dlang.org/show_bug.cgi?id=5063 >.<

-- 
Marco