Lecture 4 Outline / September 16th, 2008
========================================

Homework stuff
==============

Questions on blocking vs non-blocking, and how to handle?

GET vs POST
===========

GET puts queries on the URL

POST puts queries on the URL **and** sends them in the body of the HTTP
request.

We'll talk about how to deal with that *next* week.

Multitasking, concurrency, and pre-emptiveness
==============================================

How do you do more than one thing at a time on a computer!?

The friendly approach:
 - say, are you done yet?  excellent!  may I have some CPU?  (Windows 3.1)
 - "non-preemptive"
 - doesn't work well with "bad actors" (WANT CPU!) or bad programmers
 - actually *more* complicated to do right, in some ways
 - e.g. think about your nonblocking code due Thursday...

The less friendly approach: the traffic cop (scheduler)
 - pre-emptive
 - task scheduler coordinates things
 - less up-front work for you, but **no guarantees** on order of execution
 - how almost everything works nowadays

The bottom line is that as soon as you start using multitasking, you lose
predictability & gain stochasticity (randomness) in your execution.

Atomicity:

'atomic' operations are indivisible operations, i.e. they (look like they)
take precisely one CPU tick.

Do basic operations get interrupted?  Imagine a simple algorithm for
inserting into a list: ::

   get slot number (slot = length)
   add one element slot to list (array.add_one_slot() -> length++)
   fill slot with data (array[slot] = data)

This is not guaranteed to perform correctly as written, in presence of
threading!  Need to use locks: ::

   grab the lock:
     get slot number (slot = length)
     add one element slot to list (array.add_one_slot() -> length++)
     fill slot with data (array[slot] = data)
   release lock

Locking of resources:

Locks provide a guaranteed atomic way to execute a piece of code
nonconcurrently.

Fine grained vs coarse-grained locks:
  - more locks are better, because they let you subdivide tasks
    and do more concurrently
  - fewer locks are better because they are easier to manage and understand

Deadlock - two tasks are waiting for each other to release a lock.

(*always release the lock*; try/finally!)

This can get arbitrarily complicated.  There be dragons.  Avoid at all
costs until you know what you're doing (-> never use).

Processes vs Threads
====================

Processes:

 - heavyweight concurrency
 - less shared state between processes (disk, etc., but not memory)

os.fork() on UNIX; also see 'multiprocessing' in Python 2.6.

How do you communicate between processes?  Through the OS.  But it's slow:

Interprocess Communication (IPC) techniques:
 - shared memory
 - pipes
 - domain or network sockets
 - files

Threads:

 - lighterweight concurrency
 - shared memory space **DANGER WILL ROBINSON**
 - *atomicity* suddenly becomes important

'threading' module on Python 2.2+.

create, start, do stuff, 'join'

Avoiding shared state
=====================

Concurrency and stochasticity will only bite you when you need to
*communicate* either explicitly (IPC) or implicitly.

Any **writeable**, **shared state** must be protected: "threadsafe".

Module globals, class globals, shared namespaces...  anything that can
be accessed outside of the function that creates it is *bad*.  Local
variables are isolated and hence safe, until you say otherwise.

(This is why reentrancy came up in iterators: only the calling process
could get a handle on the iterator object!)

Python, concurrency, atomicity, and locking
===========================================

Python->C calls are automatically atomic, so most "low-level" Python
data type operations are atomic.

All other Python calls are not, so e.g. functions in threads may execute
in parallel (that's the point!)

...well, not really.  It's complicated.

Digression: I/O vs CPU-intensive multitasking

 - blocking or slow I/O calls are one reason to use multitasking
 - executing CPU-intensive tasks in parallel are another

Python multithreading is good for the first, NOT good for the second, because
only specially written C code actually runs in parallel.

---

Bottom line: concurrency is not for the faint-hearted and is best done
as simply as possible.