[Python-ideas] Concurrent safety?

[Bruce Leban]

On Mon, Oct 31, 2011 at 4:19 PM, Mike Meyer <mwm at mired.org> wrote:

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

In order to make concurrent code slightly safer, you're going to break all
existing programs that don't use concurrency. That seems to me like a new
language, not Python. You've been on this list long enough to see the
attention that's paid to backward compatibility.


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

I think the cases where non-thread-safe code won't throw an exception are
numerous, for example, the equally trivial:

    if element not in dictionary: dictionary[element] = 0

heck even this is not safe:

    dictionary[element] +=1

If you're going to tackle thread safety, it should address more of the
problem. These bugs are in many ways worse than mutating "an object in a
way that leaves things broken, but won't be detected at that point." The
above bugs may *never* be detected. I've come across bugs like that that
were in code for many years before I found them (and I'm sure that's
happened to others on this list as well).

The first thing to do is identify the problems you want to solve and make
sure that the problems are well understood. Then design some solutions.
Starting with a bad solution to a fraction of the problem isn't a good
start.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111031/46e0dffe/attachment.html>