问题
>>> import multiprocessing
>>> print multiprocessing.Manager().Lock()
<thread.lock object at 0x7f64f7736290>
>>> type(multiprocessing.Lock())
<class 'multiprocessing.synchronize.Lock'>
Why the produced object is a thread.lock and not a multiprocessing.synchronize.Lock as it would be expected from a multiprocessing object?
回答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.
回答2:
It is certainly not expected since the documentation clearly states that Lock()
Create a shared
threading.Lockobject 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.
来源：https://stackoverflow.com/questions/33800151/why-python-multiprocessing-manager-produce-threading-locks