2
>>> 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
  • 3,346
  • 3
  • 29
  • 56
  • 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

2

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
  • 963,270
  • 265
  • 3,804
  • 3,187
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
  • 20,169
  • 8
  • 66
  • 74