18

If a software project supports a version of Python that multiprocessing has been backported to, is there any reason to use threading.Lock over multiprocessing.Lock? Would a multiprocessing lock not be thread safe as well?

For that matter, is there a reason to use any synchronization primitives from threading that are also in multiprocessing?

Jason Baker
  • 192,085
  • 135
  • 376
  • 510

3 Answers3

22

The threading module's synchronization primitive are lighter and faster than multiprocessing, due to the lack of dealing with shared semaphores, etc. If you are using threads; use threading's locks. Processes should use multiprocessing's locks.

jnoller
  • 1,119
  • 6
  • 8
  • 3
    Not to mention that `multiprocessing` isn't as portable as `threading` is ;) – Antoine P. Dec 30 '09 at 22:14
  • 3
    In my program, there are multiple threads and processes. Can I use multiprocessing.Lock for thread synchronization also? – Anh Tú Mai Aug 02 '19 at 10:16
  • 2
    Just as a confirmation, acquiring and releasing 100,000 threading locks takes 0.07 seconds while doing the same with 100,000 multiprocessing locks takes 8.1 seconds. – Ian Moote Nov 25 '20 at 13:52
4

I would expect the multi-threading synchronization primitives to be quite faster as they can use shared memory area easily. But I suppose you will have to perform speed test to be sure of it. Also, you might have side-effects that are quite unwanted (and unspecified in the doc).

For example, a process-wise lock could very well block all threads of the process. And if it doesn't, releasing a lock might not wake up the threads of the process.

In short, if you want your code to work for sure, you should use the thread-synchronization primitives if you are using threads and the process-synchronization primitives if you are using processes. Otherwise, it might work on your platform only, or even just with your specific version of Python.

PierreBdR
  • 42,120
  • 10
  • 46
  • 62
  • 1
    In my program, there are multiple threads and processes. Can I use multiprocessing.Lock for thread synchronization also? – Anh Tú Mai Aug 02 '19 at 10:03
3

multiprocessing and threading packages have slightly different aims, though both are concurrency related. threading coordinates threads within one process, while multiprocessing provide thread-like interface for coordinating multiple processes.

If your application doesn't spawn new processes which require data synchronization, multiprocessing is a bit more heavy weight, and threading package should be better suited.

notnoop
  • 58,763
  • 21
  • 123
  • 144
  • I understand the difference between threading and multiprocessing. I was curious why one would want to use threading's synchronization primitives over multiprocessing's. – Jason Baker Dec 30 '09 at 14:40