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

Thanks for the patch.

That's IMO a good change, but I would only apply it to default, and not backport it.

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.

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.

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.

The differences were documented under issue23484:

https://github.com/python/cpython/commit/407c497e83b86011173fbf25e9a08b81adad5477