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?
Hmm good point, integer objects are a special case, they are shared and are thus a bad example. Perhaps only instances should be synchronizable.
(and where can you store the lock, since an int is immutable and can't have new attributes created?)
that's up to the implementation. Lock association does not effect mutability.
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)?
If they have the same id() they are the same object and thus the same associated lock. the below code will be prevented from executing at the same time.
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.
Yep that's my idea; but I doubt there's no precedence for it.
-Michel