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