Why python multiprocessing manager produce threading locks?

Question

>>> import multiprocessing
>>> multiprocessing.Manager().Lock()
<thread.lock object at 0x7f64f7736290>
>>> type(multiprocessing.Lock())
<class 'multiprocessing.synchronize.Lock'>

Why the object produced by a manager is a thread.lock and not a multiprocessing.synchronize.Lock as it would be expected from a multiprocessing object?

Gallopade

Managed objects are always proxies. I see that there are differences between multiprocessing.Lock and threading.Lock that may be significant. I guess you'd normally use multiprocessing.Lock() unless you absolutely must have a threading.Lock() object, at which point the manager makes sure it is synchronised across processes for you? – Turves

At any rate, why did you expect the manager to return a multiprocessing.Lock object? You don't need to manage that object, it already is multiprocessing-aware. – Turves

I think you gave me the answer. The manager goal is actually to proxy non multiprocessing-aware objects. – Gallopade

Answer 1

Managed objects are always proxies; the goal of the manager is to make non-multiprocessing-aware objects into multiprocessing aware.

There is no point in doing this for multiprocessing.Lock() objects; these are implemented using semaphores and are fully multiprocessing capable without assistance.

threading.Lock on the other hand is not multiprocessing aware; there are some differences between threading.Lock() objects and multiprocessing.Lock(); the latter supports a timeout when acquiring a lock, for example.

Turves

Answer 2

It is certainly not expected since the documentation clearly states that Lock()

Create a shared threading.Lock object and return a proxy for it.

As to why it returns a threading.Lock instead of a multiprocessing object is a different story I unfortunately can't answer.

Mercurochrome