[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