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