Descriptive Locking and Concurrency

Question

I'm thinking about how one would go about designing a descriptive concurrency model for an OOP language that helps simplify concurrency scenarios for programmers (no easy task, concurrency is hard).

I've read a bunch about software transactional memory, the actor model, immutability etc etc but they don't exactly seem to offer an easy model either, and while functional programming is great for some concurrency and parallel scenarios some times you simply need to mutate some kind of state. While locking is considered bad by some atleast it's fairly easy to reason about on a basic level (until you get into deadlock territory that is)

Anyways, one of the ways I thought programmers could somewhat easier handle multi-threaded scenarios was that each class is responsible for it's own thread-safety on a per method/property basis. Ie other classes can only access properties and methods, they can't really lock on anything specifically, nor should they have to.

One way to make it easier though would be to annotate methods and properties for concurrency with their indent rather than locking specifics. The compiler will then try to deduce the most performing lock from that. So assuming atomicity what do you think good annotations would be? and what are potential problems with this approach,

I'm aware that it can't solve all scenarios (like transactions) but it should help the compiler enforce the programmers intent, and might even be able to warn on potential deadlock/racing scenarios

Here's some of the attributes i thought of so far (also note that none of them are mandatory but strictly compiler "hints")

<property preference="none|read|write|fair">

   <get access="free|exclusive|shared" 
       load="unknown|many|few" 
       duration="unknown|nano|brief|long"/>

    <set access="free|exclusive|shared|upgradeable" 
       load="unknown|many|few" 
       duration="unknown|nano|brief|long" />

</property>

So for instance if get and set was set to shared access you might end up with an reader-writer lock. (do I need an attribute to control visiblity.) If duration for a write was set to nano perhaps it would use a spinlock. If there are many reads and few writes perhaps the compiler would use a different lock that if there were many writes and few reads etc etc.

Methods can be coupled into read/write pairs similarly to properties (in case you need more than one parameter).

For numeric properties that typically update based on some condition of it's value I was also thinking that instead of passing just a new value, you could pass an operator and an amount. That way you could lock, calculate the new value, see if it meets some internal condition and in that case update.

Anyways, I'm struggling a bit coming up with good attributes/notations that are somewhat easy for a programmer to wrap their head and reason about, any help and feedback deeply appreciated.

Sorry for the long rant, as I said this isn't an easy topic :)

Answer 1

The problem with locking is that--by definition--it doesn't scale. Only one thread can lock a data structure at a time.

A better solution to concurrency is generally the actor model, or some variant thereof. That is, share state by passing messages, not by locking. Erlang is an obvious example of that paradigm, but if you don't like functional languages then you might want to check out Google's Go, which is a procedural language that implements a similar message-passing mechanism (called channels, in combination with its lightweight threads, called goroutines).

Answer 2

MS already added helpers for auto-parallelism to .NET. http://msdn.microsoft.com/en-us/library/dd460693.aspx

Certain concurency problems still need to be dealt with like file locks, but memory isnt an issue AFAIK. Workflow foundation has it too. Once again, theres some limits and it can get pretty hairy. If you search MS forums on workflow with my name you can find some examples of the nastiness.