C, unlike ADA or Modula 2, is single threaded, so that an executing C program has one instruction pointer and one set of memory segments. However, the ANSI Standard C library does provide a pair of functions, setjmp() and longjmp(), for saving and restoring the contents of the machine resisters. I have used (some might say abused) these functions to implement multiple threads within a single C program.

The setjmp() and longjmp() calls are unusual, in that the longjmp() call, when successfull, never returns to the function that calls it, whereas the setjmp() call can return to the same function any number of times. The first call to setjmp(jmp_buf) saves the current state of the machine registers in the jmp_buf structure and returns 0. A subsequent call to longjmp(jmp_buf,int) restores the saved registers, causing the nonzero int specified in the calling argument to be returned by setjmp(jmp_buf) to the function that called it.

Usually longjmp() is used to abort from errors in deeply nested functions without actually returning from all the functions. An error handler is installed with a C statement like:

if (error=setjmp(buf))
    e(error);
else
    f();

For instance, a simple message passing scheme (not a very efficient one) can be implemented by placing the address of a message into an array of pointers, one for each thread, initialized to zero:

Message = (char **) calloc(N_Threads,
         sizeof(char *));

void msg_send(char *message,int
           destination)
{
    int id = ThId();
    Message[id] = message;
    do
        ThJump (destination);
    while (Message[id]);
}

char *msg_recv ()
{
    int id;
    char *m;
    do
        id = ThJump(ThNext());
    while (!Message[id]);
    m -- Message[id];
    Message[id] = 0;
    return m;
}

char *msg_wait(int godot)
{
    int id;
    char *m;
    while (!Message[godot])
        ThJump(godot);
    m = Message[godot];
    Message[godot] = O;
    return m;
}

The easiest way to prevent deadlock is simply not to share resources. For instance, one thread might handle all file IO, another all printer output. Another easy solution is to arrange resources and threads in a hierarchy, so that there is never a conflict between threads. For instance, one thread might buffer keyboard input, while a second thread reads the keyboard buffer, performs computations, and buffers window output, and a third thread reads the window buffers and displays them on the screen. Other cases are harder, and the solutions tend to be task specific.

For example, database programs can prevent deadlock, and ensure data integrity, with the concept of a transaction. A thread needing resources, such as write access to a set of data records, sets out to acquire them, one by one. If all the needed resources are acquired, the transaction succeeds and releases its resources for the next transaction. If any resource cannot be acquired, the transaction aborts, releasing all its resources. The thread then waits for a while, and tries again. Thus, no thread is ever holding a resource while waiting for another resource.

For other examples on preventing deadlock, be sure to check the relevant literature for the tasks you are implementing. A good general discussion, with C source code and further references, can be found in Andrew Tanenbaum's Operating Systems: Design and Implementation (Prentice Ha11,1987). If you fail to ensure that your application is deadlock free you can look forward to mysterious system hangs and other evidence of Murphy's Law.