[Python-ideas] Monitor implementation for the stdlib?

[Guido van Rossum]

2007/10/21, Christopher D. Leary <christopher.leary at cornell.edu>:
> Though I do think that the with statement is an excellent addition to
> the language (it avoids much of the ugliness and chance for error in
> symmetric P and V), I don't believe that it adequately covers the use
> case that monitors are intended for; namely, encapsulation and
> abstraction of the mutual exclusion involved in locking around /several
> data entities/ with /several defined functionalities/.

Locks can do that too of course.

It looks like a monitor is similar to 'synchronized' in Java except it
appears the default (once inheriting from Monitor) is synchronized,
and you need to use a decorator to declare an unsynchronized method.
Have I got that right?

> Due to how frequently this pattern is encountered, I think that monitors
> not only reduce clutter with syntactic sugar (simplicity?), but help
> encourage a more straightforward way of thinking -- several non
> re-entrant operations on shared data implies monitor usage, not lock
> acquisition all over the place.

I detect a slight prejudice against lock acquisition in your wording. :-)

> Thoughts?

It seems to be a matter of granularity. With monitors, one is required
to create a new class for each group of variables that require
synchronization. With locks, that is not necessary. Which is better
depends on the complexity of the group of variables and (especially)
the operations.

A more "Pythonic" approach would be to implement an @synchronized
decorator; Python users are more likely to be familiar with Java terms
than with classic Hoare or P and V.

(I'm sure someone has already implemented @synchronized, but it hasn't
made it into the standard library -- perhaps an indication that its
importance is more theoretical than practical, perhaps simply due to a
time lag.)

--Guido

> Chris
>
> Guido van Rossum wrote:
> > Isn't this just syntactic sugar on top of recursive locks and
> > condition variables? What's the big deal apart from conforming to a
> > historically important API?
> >
> > Note that as of python 2.5, the with-statement lets you create
> > critical sections simply by writing
> >
> >   with <some_lock>:
> >     <critical_section>
> >
> > i.e. the acquire() and release() calls are implicit in the with-statement.
> >
> > --Guido
> >
> > 2007/10/21, Christopher D. Leary <christopher.leary at cornell.edu>:
> >> I was surprised to find that there is no "monitor construct"
> >> implementation for the stdlib. I wrote one that I feel is pretty
> >> Pythonic, and I'd like it to be torn apart :)
> >>
> >> It's fairly well documented -- for most standard monitor use cases you
> >> can simply inherit the Monitor class and use the Monitor-specific
> >> condition variables. Hopefully the accompanying examples will also help
> >> to clarify the usage. They're somewhat silly, but get the idea across.
> >>
> >> As an aside, because this seems to come up in every conversation I've
> >> had about monitors in python: if I'm not mistaken, monitors are useful
> >> with or without the GIL :)
> >>
> >> Monitors are nifty tools that make complex synchronization problems
> >> somewhat simpler (though more serialized). So far as I understand it,
> >> the GIL provides single-bytecode atomicity, and monitor methods are
> >> rarely single instructions. Plus, Jython and IronPython don't have a
> >> GIL, so I would argue that monitors can still be valuable to "Python the
> >> language" even if you won't allow that they can be valuable to "Python
> >> the standard implementation".
> >>
> >> Looking forward to hearing everybody's opinions.
> >>
> >> Cheers,
> >>
> >> Chris
> >>
> >> _______________________________________________
> >> Python-ideas mailing list
> >> Python-ideas at python.org
> >> http://mail.python.org/mailman/listinfo/python-ideas
> >>
> >>
> >>
> >
> >
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)