Concurrent Programing¶

Types of Concurrency¶

Multithreading:

Multiple code paths sharing memory

Multiprocessing:

Multiple code paths with separate memory space.

Asyncronous programming:

multiple “jobs” run at “arbitrary” times.

Lots of different packages for both in the standard library and 3rd party libraries.

How to know what to choose?

• IO bound vs. CPU bound
• Event driven cooperative multitasking vs preemptive multitasking
• callbacks vs coroutines + scheduler/event loop

Concurrency in the standard library:¶

• threading: processing is interleaved to get more done (doing dishes while taking a break from cooking)
  • sched: Scheduler, safe in multi-threaded environments
  • queue: The queue module implements multi-producer, multi-consumer queues. It is especially useful in threaded programming when information must be exchanged safely between multiple threads.
• multiprocessing: processing is parallel (someone else does the dishes while you cook). Duplicates the current Python process and runs code in it.
• subprocess: allows you to spawn new processes (entirely different programs), connect to their input/output/error pipes, and obtain their return codes. Parallel, hands to OS (usually running command line programs)
• concurrent.futures: https://www.blog.pythonlibrary.org/2016/08/03/python-3-concurrency-the-concurrent-futures-module/ This is also in the asyncio package, and we go into it in more depth there)

Concurrency outside the standard library:

• Celery + Rabbitmq
• Redis + RQ
• Twisted

Advantages / Disadvantages of Threads¶

Advantages / Disadvantages of Processes¶

Processes are heavier weight – each process makes a copy of the entire interpreter (Mostly...) – uses more resources.

You need to copy the data you need back and forth between processes.

Slower to start, slower to use, more memory.

But as the entire python process is copied, each subprocess is working with the different objects – they can’t step on each other. So there is:

no GIL

Multiprocessing is suitable for computationally intensive work.

Works best for “large” problems with not much data

Mutex locks (threading.Lock)¶

• Probably most common
• Only one thread can modify shared data a any given time
• Thread determines when unlocked
• Must put lock/unlock around critical code in ALL threads
• Difficult to manage

Easiest with context manager:

x = 0
x_lock = threading.Lock()

# Example critical section
with x_lock:
    # statements using x

Only one lock per thread! (or risk mysterious deadlocks)

Or use RLock for code-based locking (locking function/method execution rather than data access)

Semaphores (threading.Semaphore)¶

• Counter-based synchronization primitive

  • when acquire called, wait if count is zero, otherwise decrement
  • when release called, increment count, signal any waiting threads

• Can be called in any order by any thread

• More tunable than locks

  • Can limit number of threads performing certain operations
  • Can signal between threads

Events (threading.Event)¶

• Threads can wait for particular event
• Setting an event unblocks all waiting threads

Common use: barriers, notification

Condition (threading.Condition)¶

• Combination of locking/signaling
• lock protects code that establishes a “condition” (e.g., data available)
• signal notifies threads that “condition” has changed

Common use: producer/consumer patterns

Queues (queue)¶

• Easier to use than many of above
• Do not need locks
• Has signaling

Common use: producer/consumer patterns

from Queue import Queue
data_q = Queue()

Producer thread:
for item in produce_items():
    data_q.put(items

Consumer thread:
while True:
    item = q.get()
    consume_item(item)

Scheduling (sched)¶

• Schedules based on time, either absolute or delay
• Low level, so has many of the traps of the threading synchronization primitives.

Timed events (threading.timer)¶

Run a function at some time in the future:

import threading

def called_once():
    """
    this function is designed to be be called once in the future
    """
    print("I just got called! It's now: {}".format(time.asctime()))

# setting it up to be called
t = Timer(interval=3, function=called_once)
t.start()

# you can cancel it if you want:
t.cancel()

demo: Examples/condensed_concurrency/simple_timer.py

Race condition:¶

A “race condition” is when the code expects things to happen in a certain order.

But with threading, multiple threads can touch the same data, and they may not do it in the order the code expects.

trival example in:

Examples/condensed_concurrenc

That also serves as an example of creating and using threads.

Subprocesses (subprocess)¶

Subprocesses are completely separate processes invoked from a master process (your python program).

Usually used to call non-python programs (shell commands). But of course, a Python program can be a command line program as well, so you can call either your or other python programs this way.

Easy invocation:

import subprocess

subprocess.run('ls')

The program halts while waiting for the subprocess to finish. (unless you call it from a thread!)

You can control communication with the subprocess via:

stdout, stdin, stderr with:

subprocess.Popen

Lots of options there!

Multiprocessing (multiprocessing)¶

• processes are completely isolated
• no locking :) (and no GIL!)
• instead of locking: messaging

Provides a similar API as threading – in the simple case, you can switch between them easily.

Messaging¶