[dmd-concurrency] Practical use of shared qualifier?

[Sean Kelly]

On Mar 15, 2011, at 10:43 AM, d coder wrote:

> I have read some literature which says that shared variables should be declared volatile (in C++). But most people say that having mutex locks is sufficient and making variables volatile just adds to inefficiency.
> 
> Now I am not an expert in concurrency. I want to ask you this. Is it not sufficient just to mark critical code segments as synchronized? This is how things are in Java and with pthread library.

Yes.  In fact, using synchronized should always be the default choice.  For the most part, entering a synchronized block can be assumed to require one volatile operation, and leaving the block may require a second volatile operation.  This is far more efficient that writing the same code using all volatile variables, for obvious reasons.

Another issue is that once execution of a shared code segment isn't synchronized, the algorithm itself will most likely have to change if it is to remain correct.  Consider inserting into a doubly linked-list.  You find the location and then update two list pointers to insert your node.  If all this is synchronized then the entire operation is atomic so you can write the code a million different ways and produce the same result.  If all the involved variables are volatile then the operations are "seen" by other threads in program order, but consider the case where two threads try inserting nodes into the same location:

class Node {}

class List(T) {
    shared void insert(shared Node insertPos, shared Node newNode) {
        newNode.prev = insertPos.prev;
        newNode.next = insertPos;

        insertPos.prev.next = newNode; // 1
        insertPos.prev = newNode; // 2
    }
}

Let's say that thread A and thread B are both inserting into the same insertPos.  Thread A executes line 1 and then stalls.  Thread B executes lines 1 and 2 and returns.  Then thread A resumes and executes line 2.  Even though all the involved operations were volatile, some of the list pointers reference thread A's new node and some reference thread B's new node (ie. the list is All Screwed Up).  And you're looking at what amounts to at least 4 volatile operations: a load of insertPos.prev, a store to newNode.prev, a store to newNode.next, a load of insertPos.prev followed by a store to insertPos.prev.next, etc.  Even if the compiler were smart enough to eliminate all unnecessary stuff and the CPU were designed such that little is actually necessary to make the code work as the compiler intends (x86 is pretty close), this function is unlikely to execute in fewer cycles than an identical synchronized function.

> In my application, when I use shared variables (and since shared is transitive) I end up making most of my code synchronized. On top of that there is no way (that I know of) to use another lock/monitor than the class object itself with synchronized class methods (AFAIK this can be done with only synchronized code blocks). In my case being forced to use the class object as monitor/lock for all class methods is giving rise to lots of deadlocks.

The intention is for there to be very few shared variables in an application, otherwise you've gained nothing over an app written in say Java.

And for what it's worth, you can have multiple objects share a monitor: use core.sync.mutex.  I think it's currently missing a function to actually assign it to an existing class instance though.  Currently, it can only become an object's monitor on construction.  I'll have to change this for 2.053.

> So I am having a doubt on the practical aspect of shared variables. Would it not be nice to leave it to the users to decide which part of the code to declare synchronized -- and also leave the choice of lock/monitor too to the coder? Presently I see that synchronized methods have to be bound to the class object as a monitor and all the methods having a shared function argument must be declared synchronized method.

I think it would be nice if the user could declare only relevant sections of his code synchronized.  Typically, you want synchronized blocks to be as small as possible to improve concurrency, etc, which isn't supported by having to label entire functions as synchronized.  But I suspect that it's much more difficult for a compiler to verify code written like this.  If you'll notice, the application of 'shared' and 'synchronized' to class members/data is basically identical to how 'const' is applied.

Personally, I really like the visibility aspect of 'shared' (ie. statics are thread-local by default, global if shared), but am less fond of how it applies to class types.  I've been hoping that a typical app will only have a few shared objects, all being things like containers.  The "vast web of shared objects" approach, as in Java, is an invitation to disaster.