Order Of Subprocesses Execution And It's Impact On Operations Atomicity

I'm learning python multiprocessing module and I've found this example (this is a bit modified version): #!/bin/env python import multiprocessing as mp import random import string

Solution 1:

You're right. The operating system kernel can and will perform context switches however and whenever it pleases to do so. The Python interpreter (or Just-In-Time compiler or whatever) is an userspace program, thus being totally controlled by the kernel.

This "kernel/user slavery" thus is passed "from father to child", or in other words, the Python program is in merced of the interpreter, which is in turn in merced of the kernel.

As such, the only way a userspace program (such as a Python application) can assure synchronization is by the use of locking primitives, such as mutexes or other synchronization primitives.

Now, in real world, what usually causes a context switch in a write to a file (such as stdout, as done by print by default), a lot of expensive operations shall be done, such as system calls, complex memory remappings and black-magic-ies, and loopback mechanisms (such as when stdout refers to a pseudo-terminal, which is the most common case today).

Solution 2:

Yes, you are right -- processes do not execute in lock-step. Modern OSes use sophisticated algorithms to decide when to switch from one process to another, but those algorithms do not impart any sort of guarantee to any process about how it will progress vs another process of the same priority (and usually only limited guarantees about processes of different priorities).

Typically, a process is blocked when it is waiting on the OS, or when the current timeslice (based off a hardware tick interrupt) expires. These occur periodically, but the amount of time a foreground task receives during a tick varies substantially depending on what is going on in the background, and when exactly the process was switched in (perhaps because another process was switched out because it blocked on I/O).

It is quite likely that if you re-run your test with different system loading, you will get different results. (And the more work each process has to do, the more likely you will see different results, as well.)