[dmd-concurrency] word tearing status in today's processors

[Michel Fortin]

Le 2010-01-27 à 11:40, Kevin Bealer a écrit :

> Tier A, the shared operations, could include byte and int64 operations, but also anything else you'd like to do with a shared object, such as modifying an associative array's contents or swapping the contents of two adjacent fields of the same object.

Hum, nice idea, but we need to be careful with that. Locking into the lock pool for performing a simple data operation is fine. But since you never know in what order each thread will take its locks in the lock pool, no thread should be allowed to take a lock while it holds a lock in the lock pool, even a separate object lock.


> Maybe this should be limited to things that might conceivably be possible using atomic CPU operations, such as atomically modifying two adjacent fields together (I'm thinking of array assignment but it's probably better for layer 1 to be conceived in terms of what phyical operation is being done), but maybe not something like sorting
> an array.

As I explained, it needs to be limited to some specific operation to avoid deadlocks.

If you see atomic operations *as an optimization*, then for that optimization to be possible you need to restrict the lock pool to only what is possible using atomics. That's because you can't mix atomic and lock pool operations on the same variable. If only one of the allowed operations can't be done with atomics, you need to use the lock pool for all others too.

Note that I said "as an optimization". If using the lock pool is done explicitly, the programer can ensure correct usage:

	shared int x;
	shared long y;

	++atomic(x); // x always accessed as atomic
	++locked(y); // y always accessed as locked

Although in this case it might be safer if this was part of the type information, perhaps through a template:

	shared Atomic!int x;
	shared Locked!long y;

	++x; // x always accessed as atomic
	++y; // y always accessed as locked

Static if could be used to choose between Atomic!T and Locked!T when specific atomic capabilities are missing:

	// check for atomic increment
	static if (is(Atomic!long()++))
		Atomic!long y;
	else
		Locked!long y;


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