[Python-ideas] Fwd: Concurrent safety?

[Bruce Leban]

On Thu, Nov 3, 2011 at 9:38 AM, Mike Meyer <mwm at mired.org> wrote:

> Attributes are names. You don't lock names, you lock objects. To
> prevent binding of an attribute, you lock the object it's an attribute
> of. If you want to prevent mutating the value of the object bound to
> the attribute, you lock that object.


You conveniently ignore my comment about the importance of database row
locking. :-)


>  > (3) What happens if one thread does:
> >
> > locking d, x: # stuff
> >
> > and another does
> >
> > locking x, d: # stuff
>
> That one I dealt with in the specification. There's an implementation
> requirement that if two locking statements share objects, the shared
> objects have to be locked in the same order. So one of the two will
> lock things in the opposite of the order they appear in the statement.
>

You're handwaving. How would that work? There's no way to know at compile
time what the correct order is. So locking just got a whole lot more
complicated. But it's worse than complicated: it's unworkable.

No, avoiding deadlock is one of the goals. That's why that requirement
> exists, and there's a further requirement that you can only nest
> locking statements if the inner one locks a subset of the outer one.
>

In other words, this code is not allowed:

def f():
    locking x:
        for y in x:
            locking y:
                y.append(1)


And neither is this:

def f(x):
    locking x:
        x.append(1)


if it is called inside code that has something locked. Which virtually all
code will do since it's required everywhere. So your proposal is that I
must lock everything before I change it but I can't lock it unless it's
already locked. That's ridiculous. You might as well have a single
semaphore to lock everything.

We're wasting our time. You said above "You don't lock names, you lock
objects." Why not? Because that was your original plan and your mind is
closed to other ideas? You want to ignore legitimate issues that aren't
convenient to your proposal. I hate to say things like "this idea sucks,"
but sometimes that's the only way to put it. I think that this proposal is
a terrible idea. It's pointless to argue about the details of something
this bad. A healthy discussion about how to make concurrency better might
be interesting but as long as all you want to do is defend your proposal,
this thread isn't sparking useful discussion. Sorry to be so blunt but I
don't see any other way to get the message across.

--- Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20111103/0b87ce55/attachment.html>