Message12410

Author jeff.allen
Recipients jeff.allen, zyasoft
Date 2019-03-29.08:08:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1553846934.69.0.90896023698.issue2711@roundup.psfhosted.org>
In-reply-to
Content
I took a second look at this because new failures turned up during #2649. I conclude that it is not valid to expect this test to pass on Jython because it tests for a particular implementation, not for atomicity per se.

The original CPython bug is https://bugs.python.org/issue13521, based on a discussion where P J Eby reminds us dict.setdefault is atomic only if the __hash__ and __eq__ of all keys are defined in C. This is because the internal logic of testing for the key and adding an entry is atomic under the GIL. If that logic calls out to Python, the GIL is (potentially) released to another thread between Python instructions.

The change introduced at that time works (I think) by finding the proper location for the key (using hash and equality) only once and inserting there if necessary. The test actually uses a __hash__ (guaranteed to collide) and __eq__ that are implemented in Python, and tests that they are called only once.

ConcurrentHashMap, and PyDictionary based on it, fails this test, because it may call __eq__ repeatedly. However, it does this under a lock (on the bucket where the key belongs). It does not matter what the implementation of __eq__ is, no other thread gets to manipulate that bucket. (Bets are off, I suspect, if your __hash__ or __eq__ manipulate the container in the owning thread.)
History
Date User Action Args
2019-03-29 08:08:54jeff.allensetmessageid: <1553846934.69.0.90896023698.issue2711@roundup.psfhosted.org>
2019-03-29 08:08:54jeff.allensetrecipients: + jeff.allen, zyasoft
2019-03-29 08:08:54jeff.allenlinkissue2711 messages
2019-03-29 08:08:54jeff.allencreate