TITLE: Introduction to concurrency


PROBLEM: rmartin@rcmcon.com (Robert Martin), 20 Jun 94

Concurrency in the context of computer applications means the ability
for code in one part of the application to execute asynchronously from
other parts.   This means that you cannot predict, by looking at the
code, where the execution thread of one part will be, from the
position of the execution thread of the other. 

Consider an application that must read a tachometer and regulate the
speed of a motor by controlling motor voltage.  The readings from the
tachometer are ready every 20ms and must be read within that period or
they will be destroyed by the next reading.  The calculation of the
motor voltage requires the last three consecutive readings and reqires
50ms.

The dillemma, of course, is that if you run the program that
calculates motor voltage, you will miss two or three of the next
tachometer readings.  A common solution to this problem is to sprinkle
the calculation portion of the problem with calls to functions that
read the tachometer.  However this is inefficient since most of those
calls will take place when the tachometer does not have any new data.

A better solution is to separate the application into two threads.
The first thread sits and waits for new tachometer readings and places
them in a buffer.  The second thread waits for three readings to
appear in the buffer and then runs the calculation.   

To manage this, we need some kind of an operating system that can
suspend what one thread is doing, and allow the other thread to
execute.  Typically this is done by saving the stack pointer and all
the machine registers of one thread, while restoring those registers
for the other thread.  This is called a context switch and is normally
done whenever there is a hardware interrupt.  

Thus, at each interrupt the operating system gains control of the
system.  It scans a list of threads, chooses the highest priority
thread.  Then saves the registers of the current thread and restores
the registers from the chosen high priority thread.  It then returns
to the chosen thread.  

In this way, many threads can be executing concurrently (not
simultaneously) with each other.  Some are high priority (like the
thread that reads the tachometer) and some are low priority (like the
thread that does the calculations).  Low priority threads are allowed
to run as long as there are no high priority threads that ready to
run.

---------------------

What has all this to do with C++.  It has been a topic of some debate
how concurrency should be integrated with the Object paradigm.
Personally, I like to hide concurrency inside objects.  To do this, I
make objects sit on top of thread boundaries.  For example in the
Tachometer example, I would have a tachometer object call the
TachValue method of the MotorController class.  This method would
contain a single tachometer reading.   It would be called by the
thread in which the tachmoeter was read.

The MotorController object would contain a buffer and would place the
tachometer reading into the buffer.  When the third reading had been
received, the MotorController would copy that buffer to a special
communications area (sometimes called a mailbox) and would then call
the "Compute" member function of the MotorController.  The Compute
method would send a signal to the operating system that the compute
thread was ready to execute.  

The compute thread would also execute in the MotorController object.
It would be a method which sat waiting for the ready signal.  It would
find the buffer in the mailbox and then crunch the values and set the
motor voltage.  It would then return the buffer to the first thread by
calling the DoneWithBuffer member function of the MotorController
class.  This function would place the buffer in a queue of buffers
that could be used by the TachValue method.

Thus the interfaces of the two objects to not let on that any
concurrency is taking place.  All the concurrency in hidden, in this
case, by the MotorController class.  In other cases there would be
many objects which participated in hiding the concurrency boundaries.

This is just one approach.   There are many others.