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 scenariosHere'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 :) 
Descriptive Locking and Concurrency
programming languages;multithreading;concurrency