Re: [Python-Dev] New PEP: 319
Look here, if want a (short) summary of current thinking on java sync primitives from Java side: http://www.jcp.org/en/jsr/detail?id=166 Python is already doing things alright, it already has got the higher-level constructs. 'synchronized' makes sense on methods to have thread-safe data structures. The rest of Java synchronization facilities should really be used to construct higher-level tools. I think 'with' is very likely a worthy addition. And maybe something along the lines of: class C(object,Synchronizable): def meth(self,...) [syncmethod]: ... I'm very skeptical about syncrhonize/asynchronize and implicit locks associated/able with all objects. regards. At 13:55 16.06.2003 -0500, Michel Pelletier wrote:
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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
On Mon, 2003-06-16 at 15:07, Samuele Pedroni wrote:
Python is already doing things alright, it already has got the higher-level constructs.
'synchronized' makes sense on methods to have thread-safe data structures. The rest of Java synchronization facilities should really be used to construct higher-level tools.
I think 'with' is very likely a worthy addition. And maybe something along the lines of:
class C(object,Synchronizable):
def meth(self,...) [syncmethod]: ...
I'm very skeptical about syncrhonize/asynchronize and implicit locks associated/able with all objects.
+1 Jeremy
participants (2)
-
Jeremy Hylton
-
Samuele Pedroni