[Python-ideas] Fwd: Concurrent safety?

[MRAB]

On 04/11/2011 01:51, Bruce Leban wrote:
>
> On Thu, Nov 3, 2011 at 9:38 AM, Mike Meyer <mwm at mired.org
> <mailto: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.
>
[snip]

If they're threads running in the same address space in CPython then
they could lock always in order of increasing address. In an
implementation of Python which uses references they could lock always
in increasing numeric value of reference (if that's possible).

This would not, of course, protect against general nested locks.