[Python-ideas] Monitor implementation for the stdlib?

[Christopher D. Leary]

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

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.

Thoughts?

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