3
>>> 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?

azmeuk
  • 4,026
  • 3
  • 37
  • 64
  • 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? – Martijn Pieters Nov 19 '15 at 09:59
  • 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. – Martijn Pieters Nov 19 '15 at 10:00
  • I think you gave me the answer. The manager goal is actually to proxy non multiprocessing-aware objects. – azmeuk Nov 19 '15 at 14:39

2 Answers2

3

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.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
0

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.

Hannes Ovrén
  • 21,229
  • 9
  • 65
  • 75