[Python-ideas] Concurrent safety?

[Matt Joiner]

I wouldn't say it necessarily has to be a new language. All too many
new languages have arisen when the problem was actually with some
specific part of an implementation, or could have been fixed with a
careful iteration.

It might be slightly off-topic, but one of Python's strengths in my
eyes has been very careful incremental improvements. Prior to 2.5
Python was of no interest to me due to various concerns that have now
been fixed. Indeed the language is significantly more consistent and
usable than it was in the past.

The last thing I (and many others) would want to see is yet another
language created, because an an existing excellent language's
implementation couldn't keep up with the times, or surmount an
obstacle. Innovations like PyPy, multiprocessing, and the currently
debated coroutines are what give Python a chance in the future.

I might be beating a dead dog, but the last thing Python should do is
roll over and die because "it's too hard". Just wanted to point out
that language != implementation.

On Tue, Nov 1, 2011 at 12:07 PM, Bruce Leban <bruce at leapyear.org> wrote:
>
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
>