More radical ideas about gc and reference counting
Andrei Alexandrescu via Digitalmars-d
digitalmars-d at puremagic.com
Wed Apr 30 16:05:29 PDT 2014
On 4/30/14, 3:54 PM, Andrei Alexandrescu wrote:
> On 4/30/14, 3:32 PM, deadalnix wrote:
>> On Wednesday, 30 April 2014 at 22:08:23 UTC, John Colvin wrote:
>>> I don't think I fully understand.
>>>
>>> Either all RC changes for a given type need to be atomic or none do,
>>> and that information is given by the type (everything that is
>>> immutable/const/shared). I don't see any feasible way of escaping
>>> this, or any advantage to a runtime convention like the odd/even trick
>>> above.
>>
>> If you CPU is decent you have some cache coherency protocol in place.
>> This won't ensure that thing appears sequentially consistent, but you
>> don't care here.
>>
>> You can proceed as follow in pseudo assembly :
>>
>> count = load count_addr
>> need_atomic = count & 0x01
>> brtr atomic
>> count = count + 2
>> store count count_addr
>> br follow_up
>>
>> atomic:
>> atomic_add count_addr 2
>>
>> follow_up:
>> // Code after increment goes here
>
> brtr_atomic won't be needed on x86.
Sorry, I misread your code. I meant to say on x86 there's no need to do
any handshake on the single-threaded case. -- Andrei
More information about the Digitalmars-d
mailing list