Re: [Python-ideas] Concurrent safety?

On Mon, Oct 31, 2011 at 4:19 PM, Mike Meyer wrote:

On Mon, Oct 31, 2011 at 3:58 PM, Bruce Leban wrote:

...

On Sun, Oct 30, 2011 at 8:11 PM, Mike Meyer 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