[dmd-concurrency] synchronized, shared, and regular methods inside the same class

Kevin Bealer kevinbealer at gmail.com
Tue Jan 5 14:31:37 PST 2010


(er...)

primatives -> primitives
primitives -> intrinsics
Kevin
On Tue, Jan 5, 2010 at 5:30 PM, Kevin Bealer <kevinbealer at gmail.com> wrote:

> That's what I was guessing.  But then I thought maybe there might be some
> magic that either inserted a lock around the block of instructions from the
> first read to the last write, or else that detected these primatives and
> emitted a warning.  Not that I'm suggesting that approach, as a general
> solution is probably impractical / full of landmines.  And I guess getting
> lock free systems right is normally considered an "experts only" kind of
> thing, except maybe the one-pointer versions like linked list.
>
> Kevin
>
> On Tue, Jan 5, 2010 at 1:21 PM, Sean Kelly <sean at invisibleduck.org> wrote:
>
>>  On Jan 5, 2010, at 10:14 AM, Kevin Bealer wrote:
>>
>> > On Mon, Jan 4, 2010 at 6:58 PM, Andrei Alexandrescu <andrei at erdani.com>
>> wrote:
>> >
>> > shared int x;
>> > ...
>> > ++x;
>> >
>> > The putative user notices that that doesn't work, so she's like, meh,
>> I'll do this then:
>> >
>> > int y = x;
>> > ++y;
>> > x = y;
>> >
>> > And the user remains with this impression that the D compiler is a bit
>> dumb. Of course that doesn't avoid the race condition though. If the user
>> would have to call atomicIncrement(x) that would be clearly an improvement,
>> but even this would be an improvement:
>> >
>> > int y = sharedRead(x);
>> > ++y;
>> > sharedWrite(y, x);
>> >
>> > When writing such code the user inevitably hits on the documentation for
>> the two intrinsics, which clearly define their guarantees: only the sequence
>> of sharedRead and sharedWrite is preserved. At that point, inspecting the
>> code and understanding how it works is improved.
>> >
>> > ...
>> > Andrei
>> >
>> > Just to clarify, this is still broken, right?  I mean that if two users
>> are calling a method that does this,
>> > the value of x will only get incremented once if their calls to
>> sharedRead/sharedWrite are interleaved?
>>
>> Yes.  You either need to call a special hardware instruction (LOCK INC on
>> x86) or use a CAS loop:
>>
>> void increment( ref shared int x )
>> {
>>    int t;
>>    do {
>>        t = atomicLoad( x );
>>    } while( !atomicStoreIf( x, t + 1, t ) );  // atomicStoreIf is a CAS
>>  }
>>
>> _______________________________________________
>> dmd-concurrency mailing list
>> dmd-concurrency at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100105/82e0410f/attachment.htm>


More information about the dmd-concurrency mailing list