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

Sean Kelly sean at invisibleduck.org
Tue Jan 5 17:12:20 PST 2010


On Jan 5, 2010, at 4:57 PM, Michel Fortin wrote:

> Le 2010-01-05 à 18:31, Álvaro Castro-Castilla a écrit :
> 
>> Is there a way that to make this eventually generalizable to any
>> operation or groups of operations that should be performed atomically?
>> 
>> something like:
>> 
>> atomic {
>> ++x;
>> }
>> 
>> or even
>> 
>> atomic ++x;
>> atomic(++)x;
> 
> I proposed this earlier:
> 
> 	++atomic(y)
> 
> The idea is to create a function template "atomic" that would return a temporary struct. All operators defined for that struct would translate to atomic operations done on y, or memory barriers for read and writes.
> 
>> This could lead to something usable as a basic STM. Is it too hard to
>> implement? STM has already been discarded from D? I know also that you
>> want to avoid new reserved keywords (what about scope(atomic) :P).
> 
> I think my proposal is completely implementable right now.

It is.  The only tricky thing about shared variables which may or may not be trickier with a struct is that copying them is kind of weird.  Copying a shared value type makes the result non-shared.  I guess the struct would have a reference to the shared value and be non-copyable for correctness.

> What I'd like from the compiler though is that it disallows all operations on shared variables. This way, you'd be forced to use atomic() with shared variables, which would make it easier to read and understand code using them.

Same here.

> For cases where you don't really want atomic operations, it should be explicit too. Perhaps we could define another function in the same style for reads and and writes with no barrier:
> 
> 	atomic(y) = 10; // with write barrier
> 	latent(y) = 20; // no write barrier, subject to propagation latency

In the atomics lib I wrote, it's possible to specify the memory barrier used for each operation.  I'm not sure how this would work into the operator overloading approach though.


More information about the dmd-concurrency mailing list