This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients jcea, jyasskin, mark.dickinson, neologix, pitrou, sbt
Date 2013-03-22.19:45:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0RaxjL-95U2dPZG411TVRVC3PodeZT1t7sWw8qw=yuuw@mail.gmail.com>
In-reply-to <1363977694.98.0.294383313454.issue17389@psf.upfronthosting.co.za>
Content
> Would that be erroneous? It can already happen because of thread switches:

That's not really the same thing. wait() would return True, which is
the right thing to do since the Event has been set at some point.
Here, it would make it possible for wait() to return immediately after
another thread clear()ed the Event, which would be just wrong.

> Charles-François: would your objections also apply to the current implementation of 'is_set'?

Yes (in OpenJDK CountDownLatch implementation, a similar method uses a
volatile variable to guarantee memory visibility.)

> For implementations with a GIL the GIL ensures there are no visibility
> issues.

Agreed.

> According to Antoine's link, Jython uses ConcurrentHashMap for its
dicts, and IronPython uses a locked map.  So in those cases also there
are no visibility issues.

Agreed.

But the question remains whether that's something which is part of the
memory model: I'm skeptical about this, since it would pretty much
imply memory barriers everywhere and disable a whole class of
caching/hoisting, which would just kill performance.
History
Date User Action Args
2013-03-22 19:45:47neologixsetrecipients: + neologix, jcea, mark.dickinson, pitrou, jyasskin, sbt
2013-03-22 19:45:47neologixlinkissue17389 messages
2013-03-22 19:45:47neologixcreate