[Python-Dev] New PEP: 319

[Jack Jansen]

On Wednesday, Jun 18, 2003, at 01:17 Europe/Amsterdam, Greg Ewing wrote:

>> Note that this same problem turns up with Greg's "synchronised class"
>> idea: if the language makes locking easy people will overuse it and it
>> will come back to bite you
>
> I don't think that should be used as a reason not to provide
> higher-level facilities such as synchronised classes. It just
> means we need to keep clearly in mind that they're not a
> magical solution that enables people to write threaded code
> without understanding the issues.

I had a half-baked idea yesterday that I'd like to dump here. I haven't
thought it over, so it's probably bogus anyway, but still here goes:-)

The main deadlock problem is acquiring a second lock while you already 
hold
a lock. But completely disallowing this in the runtime system is overly 
restrictive.
So, what we need is knowledge about which locks we can acquire and which
ones we can't. In other words, if there is a statement
	synchronize lock:
		code
then while inside "code" you will not be allowed to do any more 
synchronize
statements. (I'm re-using the synchronize statement here, but the 
object is
really a lock, not a general object, and I'm not interested in syntax 
right now.
Also, this idea would work as well, or maybe even better, with Greg's 
synchronized
class scheme).
Whether an attempt to do so results in an error or warning I'm not sure.

If the author of the code has investigated interaction between "lock",
"otherlock" and "thirdlock" and believes the interaction is safe then 
you use the form
	synchronize lock allowing otherlock, thirdlock:
		code
and "code" will be allowed to synchronize on the other two locks.

This scheme puts the annotation at the outer lock, an alternative would 
be to
put it at the inner lock. That has its advantages too, because if you 
know your
code does not block nor acquire locks you can say something like
"synchronize lock allow_holding *". A third alternative would be to 
completely
decouple the annotation from the locking code, with a statement that
says "Locks lock, otherlock and thirdlock are mutually safe".
--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman