[dmd-concurrency] What is protected by synchronization?

[Michel Fortin]

Le 2010-01-31 à 11:39, Robert Jacques a écrit :

> On Sun, 31 Jan 2010 07:51:58 -0500, Michel Fortin <michel.fortin at michelf.com> wrote:
>> We have to strike a balance somewhere. We can design something simple, safe, and unusable; we can design something complex, safe, and usable; or we can design something simple, not entirely safe, and usable. There's a compromise to draw somewhere. If you want full safety, the type system has to cope with it. If it doesn't you're restricting synchronization to small trivial cases.
> 
> First, I don't believe that their is any significant performance difference between your proposed method and the current simple and safe method. Indeed, both are prone to taking numerous recursive mutexes. At worst, simple/safe results in taking uncontested mutexes, which can be very cheap (i.e. thin-locks, etc).

I'm looking at the case where I have one object, thus one mutex, to protect a data structure. I think this is a pretty typical use case for synchronization. We probably aren't talking about the same thing.

Let's look a this from another angle.

I started this thread asking the question "What is protected by synchronization?". I think before looking for solutions we need to clearly identify the need. For instance, I think a lock need to easily protect a data structure like this one:

	struct Node(T) {
		Node* left;
		Node* right
		T value;
	}

	class TreeMap(T) {
		Node!(T)* root;
		...
	}

In the above case, no one should access access the content of the map (the whole tree) without holding the TreeMap's lock, otherwise races might ensue. Those races might happen at the cache-line level in the hardware, but could also happen algorithmic level if two threads try to manipulate the nodes at the same time.

This is the need. Can we agree this is a typical use case we want to address?

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