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 is
an int, so the statement
synchronize self.counter: ...
must be using some particular int (say, 3) for purposes of
synchronization. What sense does this make? (and where can you store
the lock, since an int is immutable and can't have new attributes
created?) On the other hand, if the thing you're locking is the counter
attribute 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 two
snippets 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-1
My other question concerns the 'asynchronize' portion of your proposal.
Is this from Java, or is it your own innovation? I didn't turn up
anything about it in several web searches, but I'm not familiar enough
with java to know for sure.
Jeff
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