[Python-ideas] Concurrent safety?

[Mike Meyer]

On Mon, Oct 31, 2011 at 3:58 PM, Bruce Leban <bruce at leapyear.org> wrote:

> On Sun, Oct 30, 2011 at 8:11 PM, Mike Meyer <mwm at mired.org> wrote:
>
>> Any attempt to mutate an object that isn't currently locked will raise
>> an exception. Possibly ValueError, possibly a new exception class just
>> for this purpose. This includes rebinding attributes of objects that
>> aren't locked.
>>
>
> Do you mean that at any time attempting to mutate an unlocked object
> throws an exception?


Yes, that's the idea.  There are some exceptions, but you have to
explicitly work around that restriction.


> That would mean that all of my current code is broken.


Pretty much, yes. It's like adding garbage collection and removing
alloc*/free. It's going to break a *lot* of code. That's why I said "not in
3. and possibly never in cPython."



> Do you mean, that inside the control of 'locking', you can't mutate an
> unlocked object? That still breaks lots of code that is safe. You can't use
> itertools.cycle anymore until that's updated in a completely unnecessary
> way:
>
> def cycle(iterable):
>     # cycle('ABCD') --> A B C D A B C D A B C D ...
>     saved = []
>     for element in iterable:
>         yield element
>         saved.append(element)  *# throws an exception when called on a locked iterable*
>     while saved:
>         for element in saved:
>               yield element
>
>
According to what I wrote, yes, it does.Since the list being mutated is
only visible inside the function, it doesn't need to be. It might be
possible to figure out that this is the case at compile time and thus allow
the code to run unmodified. But that's 1) hard, 2) will miss some cases, 3)
seems like a corner case. This proposal would break enough code that not
breaking this case doesn't seem to be worth the effort. That's a question
that needs to be answered.



> I think the semantics of this need to be tightened up.
>

That's why I brought it up. I'm trying to get more eyes on the issue.


> Furthermore, merely *reading* an object that isn't locked can cause
> problems. This code is not thread-safe:
>
>     if element in dictionary: return dictionary[element]
>
> so you have to decide how much safety you want and what cost we're willing
> to pay for this.
>

You're right - it's not thread safe. However, it also doesn't suffer from
the problem I'm trying to deal with, where you mutate an object in a way
that leaves things broken, but won't be detected at that point. If it
breaks because someone mutates the object underneath it, it'll throw an
exception at that point. I know you can construct cases where that isn't
so. Maybe we need two types of locking - one that allows readers, and one
that doesn't.  I could live with that, as you'd still have to consider the
issue where you mutate the object.

   <mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111031/549ea9a2/attachment.html>