[Python-ideas] Monitor implementation for the stdlib?

Guido van Rossum guido at python.org
Mon Oct 22 01:57:56 CEST 2007

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

i.e. the acquire() and release() calls are implicit in the with-statement.


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

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

More information about the Python-ideas mailing list