[dmd-concurrency] A synchronized storage class?

[Michel Fortin]

Le 2010-01-07 à 10:00, Andrei Alexandrescu a écrit :

> What real-world scenarios would require such a member?

I just realized that it might not be necessary, but it all this depends on the way shared propagates, so I'll need to clear that up first. Let's say I have this class:

	class A {
		int x;
		shared int y;
	}

	auto a1 = new A;
	auto a2 = new shared(A);

Here's what I'd expect from this (from what I explained earlier and from how const propagates):

	a1.x  is not shared  synchronization has no effect (a1 is not shared)
	a1.y  is shared  only accessible through atomic ops
	a2.x  is shared  synchronization is needed for access
	a2.y  is shared  only accessible through atomic ops

The issue is with a1.y. It being always only accessible through atomic ops could be bad if what I want to implement is a lock-free algorithm:

	class A {
		int x;
		shared int y;

		void increment() shared {
			synchronized { ++x; }
			++atomic(y);
		}
		void increment() {
			++x;
			++atomic(y);
		}
	}

It's good that the lock-free algorithm is forced to use atomic ops, but it's wasteful when the object itself is not shared. So the above could be changed like this:

	a1.x  is not shared  synchronization has no effect (a1 is not shared)
	a1.y  is not shared  no need for atomic ops, synchronization has no effect
	a2.x  is shared  synchronization is needed for access
	a2.y  is shared  only accessible through atomic ops

Now I've made a1.y not shared because its parent is not shared, even though this is counterintuitive since y is clearly marked as shared in the class. But now you can write your algorithm like that:

	class A {
		int x;
		shared int y;

		void incrementY() shared {
			synchronized { ++x; }
			++atomic(y);
		}
		void incrementY() {
			++x;
			++y;
		}
	}

If that's what we want, then we don't need another qualifier.


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