[Python-ideas] Fwd: Concurrent safety?

[Mike Meyer]

On Thu, Nov 3, 2011 at 2:35 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Mike Meyer wrote:
>
>> This case would still throw an exception, because what needs to be
>> locked isn't balance, but whatever balance is an attribute of.
>
> All right, suppose we have an "account" object that
> holds the balance. Now we can do
>
>   locking account:
>      account.balance = account.balance + deposit
>
> That's okay. But what if there are two accounts
> involved, and we want to do
>
>   account1.balance = account1.balance - amount
>   account2.balance = account2.balance + amount
>
> These two operations need to be done atomically,
> but there is no single object to lock, so we have
> to lock both of them -- and then there is an
> opportunity for deadlock if two threads do this
> in different orders.

That's why the proposal specifies that locking statements determine
the order of the locking, and require that any two locking statements
lock all objects they have in common in the same order - at least
during one run of the application. So the above is done by:

    locking account1, account:
        # stuff

If a second locking statement does "locking account2, foobar,
account1", then account1 and account2 will be locked in the same order
by both statements.

>> and there's a further requirement that you can only nest
>> locking statements if the inner one locks a subset of the outer one.
> Then it's *impossible* to solve the above problem,
> because neither of the objects needing to be locked
> is contained in the other.

I wasn't clear enough. The sets I'm talking about are the objects
being locked, not anything they may contained, in order to prevent
deadlocks. So if you start by doing:

    locking account1, account2, foobar:

and then later on - but with those locks still held - do

    locking account1, account2:

things work fine (the second locking is a nop). However, if you do
(under the same condition):

    locking account1, aardvark:

you get an exception - the outer lock has to lock aardvark as well.
And yes, the implications still need to be worked out.

> The notion of containment is not even well defined
> in general, because Python objects can form arbitrary
> graphs

Containment has a very specific meaning for this specification, in
that an object only contains things it has a direct reference to. That
should be spelled out, or maybe I need to use a better word.

   <mike