[Python-Dev] New PEP: 319

[Samuele Pedroni]

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