Movatterモバイル変換
[0]ホーム
[Python-Dev] New PEP: 319
Jeff Eplerjepler@unpythonic.net
Mon, 16 Jun 2003 07:37:55 -0500
On Mon, Jun 16, 2003 at 02:19:19AM -0500, Michel Pelletier wrote:> def change(self, delta=1):> synchronize self.counter:< self.counter += delta # typo corrected by jepler>> 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 don't see how this can possibly work. It looks like self.counter isan int, so the statement synchronize self.counter: ...must be using some particular int (say, 3) for purposes ofsynchronization. What sense does this make? (and where can you storethe lock, since an int is immutable and can't have new attributescreated?) On the other hand, if the thing you're locking is the counterattribute of slot (and ignoring for a moment where the lock is stored)then what if self.counter is a list but id(self.counter) ==id(globallist)? Then the 'synchronize' will not prevent these twosnippets from executing at the same time: def change(self, delta=1): synchronize self.counter: for i in range(delta): self.counter.append(i) synchronize globallist: globallist.pop()globallist.pop() could now see a different item than delta-1My other question concerns the 'asynchronize' portion of your proposal.Is this from Java, or is it your own innovation? I didn't turn upanything about it in several web searches, but I'm not familiar enoughwith java to know for sure.Jeff
[8]ページ先頭