Movatterモバイル変換
[0]ホーム
[Python-Dev] New PEP: 319
Jack JansenJack.Jansen@cwi.nl
Wed, 18 Jun 2003 13:28:53 +0200
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'tthought it over, so it's probably bogus anyway, but still here goes:-)The main deadlock problem is acquiring a second lock while you already holda 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 whichones we can't. In other words, if there is a statementsynchronize lock:codethen while inside "code" you will not be allowed to do any more synchronizestatements. (I'm re-using the synchronize statement here, but the object isreally 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 synchronizedclass 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 formsynchronize lock allowing otherlock, thirdlock:codeand "code" will be allowed to synchronize on the other two locks.This scheme puts the annotation at the outer lock, an alternative would be toput it at the inner lock. That has its advantages too, because if you know yourcode does not block nor acquire locks you can say something like"synchronize lock allow_holding *". A third alternative would be to completelydecouple the annotation from the locking code, with a statement thatsays "Locks lock, otherlock and thirdlock are mutually safe".--Jack Jansen, <Jack.Jansen@cwi.nl>,http://www.cwi.nl/~jackIf I can't dance I don't want to be part of your revolution -- Emma Goldman
[8]ページ先頭