[Python-ideas] Monitor implementation for the stdlib?
Adam Olsen
rhamph at gmail.com
Mon Oct 22 20:39:20 CEST 2007
On 10/22/07, George Sakkis <george.sakkis at gmail.com> wrote:
> On 10/22/07, Adam Olsen <rhamph at gmail.com> wrote:
> > On 10/22/07, George Sakkis <george.sakkis at gmail.com> wrote:
> > > On 10/22/07, Adam Olsen <rhamph at gmail.com> wrote:
> > >
> > > > A method is often *NOT* the
> > > > correct granularity to achieve a thread-safe API! Consider:
> > > >
> > > > l = ... some "thread-safe" list ...
> > > > if l:
> > > > x = l.pop()
> > > >
> > > > There's two method calls, so you cannot guarantee the object hasn't
> > > > changed between them. I get the impression this is regarded as a
> > > > major mistake in Java's extensive use of monitors - plastering locks
> > > > everywhere just isn't good enough.
> > >
> > > My Java's kinda rusty but IIRC one can use synchronized blocks on an
> > > object to achieve finer granularity.
> >
> > You need coarser granularity to achieve correctness in this case.
>
> Well I was talking from the POV of the enclosing method, i.e. something like:
>
> l = ... some "thread-safe" list ...
> synchronized(I) {
> if l:
> x = l.pop()
> }
aka:
l = ... some "thread-safe" list ...
with l.lock:
if l:
x = l.pop()
But if this "list" doesn't provide a thread-safe API in the first
place it has no business providing a lock.
--
Adam Olsen, aka Rhamphoryncus
More information about the Python-ideas
mailing list