> 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
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