Title: multiprocessing RLock and Lock raise incorrect exceptions when releasing an unlocked lock.
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: duplicate
Dependencies: 23484 Superseder: SemLock acquire() keyword arg 'blocking' is invalid
View: 23484
Assigned To: Nosy List: davin, iritkatriel, neologix, r.david.murray, sbt, steinn
Priority: normal Keywords: patch

Created on 2014-04-24 06:00 by steinn, last changed 2021-06-21 12:03 by iritkatriel. This issue is now closed.

File name Uploaded Description Edit
release_exceptions.patch steinn, 2014-04-24 06:00 review
Messages (6)
msg217117 - (view) Author: Steinn Steinsen (steinn) * Date: 2014-04-24 06:00
In the documentation of multiprocessing the locks, RLock and Lock, 
are said to be clones of their respective threading synchronization primitives.

There is an inconsistency in what exceptions are raised when an
unlocked lock is released. According to the threading documentation a 
RuntimeError should be raised.

Lock.release raises ValueError 
RLock.release raises AssertionError

Tested this in python 2.7, 3.2, 3.4, 3.5 and broken in all those versions.

The attached patch fixes this for 3.5
msg217279 - (view) Author: Charles-Fran├žois Natali (neologix) * (Python committer) Date: 2014-04-27 16:22
Thanks for the patch.

That's IMO a good change, but I would only apply it to default, and not backport it.
msg218531 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-05-14 13:55
As a historical note, the docs are probably correct...but at some point relatively recently we fixed the inconsistency in what was raised in the thread and threading modules, but obviously no one noticed that multiprocessing had the same issue.  It could be that a comment should be added to the thread/threading code mentioning the multiprocessing clones, and vice versa.  Or perhaps the code can be unified?  I suspect the clones exist primarily because multiprocessing was originally an external project.
msg237085 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2015-03-02 21:03
The discussion in issue23484 is leading to a recommendation that the docs be changed to reflect the actual behavior of multiprocessing's Lock and its close relatives.

As far back as 2.6.9, calling release() on an unlocked threading.Lock triggered a thread.error Exception whereas doing the same on multiprocessing.Lock triggered a ValueError.  This discrepancy in the behavior of Lock between modules turns out to not be a recent development.

If issue23484 moves forward with changing the documentation to reflect reality, this issue would be addressed as well.
msg239089 - (view) Author: Davin Potts (davin) * (Python committer) Date: 2015-03-24 03:26
Since the time of its introduction in 2.6, a call to multiprocessing.Lock.release on an already unlocked lock resulted in behavior that did not match that of threading.Lock.release (which raised a thread.error as far back as 2.4 and probably longer than that historically).  Similar can be said of the RLock analogs.

This is but one discrepancy of many as described in issue23484.  Behavior in threading's locks going back as far as 2.2 has not been / is not matched in multiprocessing's locks since its arrival -- it does not appear to be a case of recent changes opening a rift between these two modules' locks' behavior.

Changing the behavior that has existed in multiprocessing's locks since its arrival in the stdlib would break existing code which depends upon it (as referenced in msg236431) so I will propose a patch for issue23484 to move ahead with correcting the documentation to describe the established behaviors of multiprocessing's locks -- as part of that proposed documentation change, the behaviors discussed here should also be covered.
msg396235 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-06-21 12:03
The differences were documented under issue23484:
Date User Action Args
2021-06-21 12:03:02iritkatrielsetstatus: open -> closed

superseder: SemLock acquire() keyword arg 'blocking' is invalid

nosy: + iritkatriel
messages: + msg396235
resolution: duplicate
stage: patch review -> resolved
2015-03-24 03:26:55davinsetversions: + Python 2.7, Python 3.4
2015-03-24 03:26:01davinsetmessages: + msg239089
2015-03-02 21:03:46davinsetnosy: + davin
dependencies: + SemLock acquire() keyword arg 'blocking' is invalid
messages: + msg237085
2014-05-14 13:55:57r.david.murraysetversions: - Python 2.7, Python 3.2, Python 3.4
nosy: + r.david.murray

messages: + msg218531

stage: patch review
2014-04-27 16:22:54neologixsetnosy: + neologix
messages: + msg217279
2014-04-24 18:09:58ned.deilysetnosy: + sbt
2014-04-24 06:00:51steinncreate