>> 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. I should add that I am experimenting with this in Jython, not CPython which is why I said it's up to the implementation. I immagine CPython would add some unitialized behind-the-scenes pointer to a lock object and lazily initialize and lock it when the object is first sychronized. Any subsequent asynchronizing or sychronizing would use this lock until the object is garbage collected. >> 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. Ah I'm going over all the emails I got today for my next revision and sorry I missed where you said "attribute of the slot" the first time I read it. You meant, I gather, sychronizing on the slot and not the value it stores. Sorry to confuse things. I do not think sychronizing on the slot is the right thing (as I said above). Thanks for everyones comments, please keep sending them if you have them. -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