> > On Monday, Jun 16, 2003, at 09:19 Europe/Amsterdam, Michel Pelletier > wrote: >> No explicit lock is necessary. Any object may be synchronized upon >> (except, perhaps, None). The first time an object is synchronized, a >> lock >> is invisibly associated with it behind the scenes, you cannot (and >> should >> not) access this lock. The lock exists for the life of the object it >> synchronizes. When a synchronize block is entered, the lock is >> acquire()d >> and and release()d when the block is exited. > > I think this is a bad idea, after pondering it for a while[*]. There > will always be situations where you want to lock multiple objects, Can you be more explicit? I'm not sure I understand. In Python as it is now, you cannot "lock" an object, only a lock (unless the object is like a condition variable, which proxies a lock). Any association between that lock and any number of objects is a concept that must be maintained in your head and visually in your code. PEP 319 proposes automating the simplest and most common cases of these associations. > and > before you know it you'll end up with extra objects that hold no data > but only a lock What are extra objects? If your objects are no longer necessary they are garbage collected like all others, including their locks. is your concern memory consumption? >. And then it would have been better to design the > language feature that way in the first place. Explicit is better than > implicit:-) > > [*] I wondered for a while whether locking only a single object would > maybe steer people away from potentially deadlocking code, but I > believe it's the other way around: with explicit locks you actually > have to think of the locks you need, whereas with implicit locks you > don't, so you write deadlocking code more often. I belive the reverse, synchronize will reduce user error and deadlocking code. with explicit locks programmers will forget, or become confused, with when and how to explicitly lock and unlock. 'synchronize' locks at the beginning of the block and unlocks at the end. There is no forgetting. -Michel -Michel
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4