[dmd-concurrency] What is protected by synchronization?

Michel Fortin michel.fortin at michelf.com
Sat Jan 30 12:30:04 PST 2010


Le 2010-01-30 à 9:57, Michel Fortin a écrit :

> Since we're talking about synchronization again, I think this is a problem that should be addressed.

(Replying to myself)

Robert's comment in the other thread makes me realize I've skipped over something important in my previous message: fields inside a synchronized object shouldn't 'shared'. Despite being usable from many threads due to synchronization, they behave much more like thread-local fields where the thread they belong to changes depending on who holds the lock. 

So what I'm proposing is that a synchronized object contains non-shared fields unless explicitly marked shared. Those fields wouldn't be accessible from anywhere except inside a synchronized block. Inside a synchronized block they are accessible and treated as thread-local.

The only thing lacking is a way to avoid them from escaping when passing them to functions. If we deem it necessary, we could add a type modifier for that (although it probably won't enough by itself).

But as long as the programmer doesn't let those references escape, things will run smoothly. I think having fined-grained controls over what is protected by the lock and what will use atomic operations is a necessity if you want to achieve decent performances.

More examples:

	synchronized class SyncObject {
		shared(int)*[] data;
		// only the last part can be shared, 
		// the rest is protected by the object's lock.

		SyncObject next;
		// the reference is protected by the object's lock,
		// but the object itself can be shared since it is synchronized.

		char[] buffer;
		// the whole thing is protected by the object's lock.

		SomeStruct s;
		// s.a is protected by the object's lock.
		// s.b is shared as per struct's definition.
		// s.test() is callable under the object's lock.
	}

	struct SomeStruct {
		int a;
		shared(int) b;

		void test() {
			a += 1;
			b += 1; // this one is always atomic.
		}
	}


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





More information about the dmd-concurrency mailing list