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

[Michel Fortin]

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.


> that would create a variable doing the work of "y", but in case you
> want to specify the operations.
> 
> atomic {
>  int y = x;
>  y++;
>  x = y;
> }

This syntax I don't like. While enclosing one operation in an atomic block is fine, here it looks as though all those actions are done in one atomic operation, which isn't at all the case. How hard is it to write this instead:

	int y = atomic(x);
	y++;
	atomic(x) = y;

Here at least it's obvious that the whole isn't an atomic operation. And somehow it also express that something could happen to x between the two assignments.


> "y++" won't be performed as an atomic operation because the compiler
> will detect is a variable not shared. So it would be about the same
> thing as the previous.

atomic(y) could be overloaded so that it doesn't do expensive atomic operations when y isn't shared.


> 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.

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.

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


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/