[Python-ideas] Fwd: Concurrent safety?

[MRAB]

On 04/11/2011 03:53, Stephen J. Turnbull wrote:
> 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?
>
In CPython the implementation refers to an object by its address, but
my understanding is that in an implementation which uses references the
reference is actually an index into a table which contains the
addresses of the objects, therefore you would be locking in order of
increasing index.

> 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.)
>