Programming using shared memory

We started the lecture, illustrating the use of copper, the supercomputer we will use for our shared memory programming.

The difference between UNIX processes and threads lies mainly in that processes ought to be considered as completely separate programs, with their own memory. Using the fork() and join() is very much like distributed memory programming. Threads are much faster to create than processes. Threads created by the same program share the memory, i.e.: they all have access to the same variables.

Our very first program using threads is an example of a producer/consumer situation. Imagine a user viewing a sequence of different picture files which need decompressing. While the user (consumer) views the current picture, the computer (producer) may already decompress the next picture concurrently so that when the user gets a faster response when requesting the next picture. A cartoon of this application is the program get_next.c which runs as follows:

prompt] get_next 5 8 1
buffer :  1 2 3 4 5
press enter to continue
buffer :  6 7 8 9 10 11 12 13
press enter to continue
buffer :  14
press enter to continue
prompt]
The concurrent version is the program buffer.c using threads, execution on copper goes like
cu12:~/Notes/L26167% buffer 3 5 1
buffer :  1 2 3
press enter to continue
buffer :  4 5 6 7 8
press enter to continue
buffer :  9
press enter to continue
cu12:~/Notes/L26168%

We ended the lecture sketching the problems with sharing data, offering locks or semaphores as a solution. As an illustration of deadlock, we sketched the "dining philosophers" example from operating system concepts.

Bibliography