sbt <shibt...@gmail.com> added the comment:
krisvale wrote
----
There is no barrier in use on the read part. I realize that this is a subtle
point, but in fact, the atomic functions make no memory barrier guarantees
either (I think). And even if they did, you are not using a memory barrier
when you read the 'timeouts' to perform the subtraction. On a multiprocessor
machine the two values can easily fall on two cache lines and become visible to
the other cpu in a random fashion. In other words: One cpu decreases the
"owner" and "timeouts" at about the same time. A different thread, on a
different cpu may see the decrease in "owner" but not the decrease in
"timeouts" until at some random later point.
----
>From the webpage you linked to:
----
Sometimes the read or write that acquires or releases a resource is done using
one of the InterlockedXxx functions. On Windows this simplifies things, because
on Windows, the InterlockedXxx functions are all full-memory barriers—they
effectively have a CPU memory barrier both before and after them, which means
that they are a full read-acquire or write-release barrier all by themselves.
----
Interlocked functions would be pretty useless for implementing mutexes if they
did not also act as some kind of barrier: preventing two threads from
manipulating an object at the same time is not much use if they don't also get
up-to-date views of that object while they own the lock.
Given that mutex->timeout is only modified by interlocked functions, an
unprotected read of mutex->timeout will get a value which is at least as fresh
as the one available the last time we crossed a barrier by calling
InterlockedXXX() or WaitForSingleObject().
Note that if the read of mutex->timeouts in this line
if ((timeouts = mutex->timeouts) != 0)
gives the "wrong" answer it will be an underestimate because we own the lock
and the only other threads which might interfere will be incrementing the
counter. The worst that can happen is that the fast path remains blocked:
consistency is not affected.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11618>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
