[Python-ideas] Fwd: Concurrent safety?

[Stephen J. Turnbull]

MRAB writes:
 > On 04/11/2011 01:51, Bruce Leban wrote:

 > >      > (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?
 > 
 > If they're threads running in the same address space in CPython then
 > they could lock always in order of increasing address.

OK, I think that works.

 > In an implementation of Python which uses references they could
 > lock always in increasing numeric value of reference (if that's
 > possible).

That doesn't make sense to me; if it's not an address, how do you know
it's unique (you know the object is unique, of course, but there may
be other references)?  If the reference is not unique, how do you know
that some other thread hasn't locked it via a different reference?

I think for this to be workable you would need to use something like a
lock tick that would increase with each lock taken, and store that in
the object.  Then you would lock the objects in order of their ticks,
with unlocked objects coming last.  (You'd have to be careful about
the wraparound, though, and that could double or triple the
performance hit for incrementing the tick and determining lock order.)