The concepts of user, session, and process are easy to visualize and understand because they relate to "real world" objects. In some sense, a user is a person, a session is a terminal, and a process is a program. Threads are a bit more difficult to understand because they don't have this real-world aspect. A thread exists only as an ephemeral object called an execution stream.

In a single-thread system, each process can have only one entry in the execution list, while a multi-thread system allows a process to have several scheduling entries. That is, multi-threading means that the operating system manages two or more execution streams for the same program.

Perhaps the best way to visualize multi-threading is to think of the initial execution stream as the parent thread and to view the child threads as functions that execute concurrently with the parent. You create a thread by telling the operating system, "Transfer control to this function, but return to me before the function is finished." Then every so often you ask the operating system, "Is that function finished yet? If so, give me its return code."

As the spreadsheet grows, the computation takes longer and longer. At some point the delays begin to annoy the user, whose terminal becomes sluggish or locked out while the function executes. A multi-threading system like OS/2 solves this problem easily by calling the computation function as a child thread running at a lower priority than the parent. It will then go about its business in the background while the parent thread continues to interact with the user.

Notice that it is easier and more efficient to treat the computation function as a thread instead of creating a separate process for it. Since the only resource that this procedure needs is the spreadsheet data, it would be wasteful to have the operating system go through all the work of building I/O and other resource management structures that would never be used.

In other words, if you want to perform some operation using the resources already allocated for your process, it is usually more efficient to create a thread instead of another process. When you ask the operating system to create a thread, it need only make another entry in the execution list. Process creation, on the other hand, involves a lot of time-consuming resource allocation operations. This distinction has led some people to refer to threads as lightweight processes.

Operating systems usually provide a variety of interprocess communication (IPC) techniques to facilitate this coordination. In addition, most operating systems require explicit declarations of shared resources at the user, session, and process levels. Two processes may share memory or I/O devices only if they both inform the operating system of their intention to do so. Two users may share a file only if the owner agrees and so informs the operating system. Several application programs may share the same terminal session only if they work through some arbiter, like the Presentation Manager, which prevents the screen appearance from confusing the user.

At the thread level, coordination problems are more subtle and more severe. The threads of a process share all of that process's resources, making the chance of unwanted interference very high. For example, consider the error code errno that C programmers use to determine if a library function has failed. Suppose one thread calls a library function, which takes an I/O break. During the break, a second thread calls a library function which places an error code into errno. But before the second thread can read errno, the first thread resumes and changes it to a different value. The second thread has been compromised and may make an incorrect decision because the threads have not coordinated their use of errno, which is a shared resource.

This problem would not occur if all threads used a semaphore or other IPC mechanism to control their access to errno. In fact, the ANSI C committee decreed that programmers should not assume that errno is simply a memory location, but should code it as a macro that invokes a function returning the appropriate value. In other words, a C compiler could implement errno as

#define errno get_errno()

The trouble with this approach is that the typical C compiler/library system is chock full of these subtly shared memory areas. For instance, what about the static work areas used by many floating point libraries? What about the stream I/O data structures and buffers? What about the static data areas used by the ANSI-defined time and date functions? The library would be much slower and larger if each of these shared objects had to be protected by a semaphore.

Furthermore, my experiences with OS/2 demonstrated that it is very easy for an application programmer to unwittingly define data items that other threads corrupt. This situation often occurs when additional threads are introduced into a debugged program in order to make it more efficient. Suddenly the program behaves strangely because the threads are not coordinating their access to shared objects which were previously used in a serial fashion.

• Tell the compiler which data objects must be replicated for each thread.
• Tell the compiler that a certain sequence of statements should not be interrupted by another thread.
• Tell the compiler that a certain sequence of statements should be controlled by a semaphore.

The programmer defines and declares private objects using the same syntax as near, far, and huge, which were introduced by Microsoft in order to handle various size pointers. These keywords, together with const and volatile defined by ANSI, specify the access method for data objects. The other data definition keywords, such as int and float, are used to specify an object's "shape".

(1) private int errno;
(2) int private counter = 200;
(3) char private buffer[512];
(4) char*(private ptr1);
(5) int private *ptr2;
(6) float private *(private ptr3);

Using the private keyword with pointers is a bit more complicated, although no more so than using near, far, and huge. When forming such a definition, you must ask yourself, "What is private? The pointer itself, the object being pointed to, or both?" Examples four, five, and six illustrate each of these cases. Example four defines a pointer that will be replicated for each thread. Notice that the private keyword appears closest to the object name, ptr1. Example five defines a normal pointer to a private integer, and example six defines a private pointer to a private floating point number. You could omit the parentheses in these three examples, but they do make the statements easier to understand.

I must point out a terminology problem that Microsoft created in the documentation of the near, far, and huge keywords. Consider the two statements:

char far *ppp;
char *(far qqq);

char private *ppp;
char *(private qqq);

(1) extern private int errno;
(2) extern int private counter;
(3) extern char private buffer[512];
(4) extern char*(private ptr1);
(5) extern int private*ptr2;
(6) extern float private
       *(private ptr3);

int ni, private pi;
int *np, private *pp;
(1)  np = ∋ (Correct)
(2)  np = π (Incorrect, perhaps)
(3)  pp = π (Correct)
(4)  pp = ∋ (Incorrect, perhaps)

In practice, a compiler would probably not complain about the fourth statement because most computer addressing methods can cope with this type of assignment. Similarly, the second statement would usually be accepted in the large memory model because normal pointers are large enough to hold the addresses of private objects. Similar loopholes exist in Microsoft's implementation of near, far, and huge. Nonetheless, as the concept of C access methods becomes more widely accepted, you will be ahead of the game if you use the more strict (and therefore more portable) rule stated earlier.

int private counter = 200;

int private *ppp = &counter;
/*** WRONG ***/

foo (void)
{
int private *qqq = &counter;
int private *rrr;

rrr = &counter;
*rrr -= 20;
}

This technique works in the Lattice D, L, and H memory models because SS can take on different values in those models. Since in the S and P models SS must always point to the default data segment, DGROUP, the private keyword is not allowed in those models. Given that most OS/2 programs use the large model, this is not a serious restriction.

Earlier I mentioned that you must use the private keyword consistently. If an object is defined as private, then all external declarations of that object must also use the keyword. In order to catch inconsistent declarations at link time, the Lattice compiler automatically appends an @ character to each private name. Thus, the declaration

private int counter;

The Lattice implementation of private will not work with Microsoft's compiler because Microsoft requires SS to contain the DGROUP address in all memory models, an unfortunate design decision on Microsoft's part. It not only makes multi-thread and re-entrant C programming more diffficult, but it also limits the stack size to substantially less than the 64K allowed by Lattice and other compilers.

Nonetheless, the private keyword could be implemented in the Microsoft environment by using the more general technique that Lattice employs in the 80386 32-bit mode.

In the flat addressing mode, the stack segment register SS does not change for each thread. Instead, OS/2 allocates the thread stacks within the 32-bit addressing spectrum and adjusts the stack pointer register SP for each thread. This means that we cannot use SS as the base address for private data; we use EBX instead. The compiler then generates EBX-relative addressing to access private data objects. Each time thstart is called, the compiler allocates a new private data area, copies the current thread's data to it, and sets EBX to that area for the new thread.

Although reserving a base register for private data might seem wasteful, it does not seriously impair the compiler's ability to generate good 386 code. The flat address model eliminates many of the inefficiencies caused by segmentation, and the 386's 32-bit registers make pointer manipulation and floating point computations much easier. In light of these major architectural improvements, the reservation of the EBX register is small price to pay for the advantages of the private keyword.

When you define a critical function, the compiler generates a special prolog and epilog, which call library routines named _CXENTRY and _CXEXIT, respectively. _CXENTRY uses the OS/2 Application Program Interface (API) service named DosEnterCritSec, and _CXEXIT uses DosExitCritSec.

Since _CXENTRY and _CXEXIT are just library functions, you can replace them with versions that are appropriate for another environment. For example, when writing an I/O driver, you probably want critical sections to actually block interrupts. Likewise, in a shared database scenario where threads may interfere with other processes, the critical section routines could use a global semaphore.

Note that critical functions can be nested. The protection begins when the first (i.e., outermost) critical function is entered and ends when that function returns. Nested critical functions may require that some versions of the _CXENTRY and _CXEXIT routines maintain an up-down counter.

With this method a semaphore controls a related set of shared data objects. You then request the operating system to give you control of the appropriate semaphore before accessing any of the controlled objects. If no other process or thread is using the semaphore, it is assigned to you; otherwise the operating system suspends your thread until whoever owns the semaphore releases it. After finishing with the data, you again call the operating system to release the semaphore.

Although this semaphore protocol is simple, it's tedious to code each time you access shared data. The prolog and epilog keywords place this burden on the compiler in a way that should make your programs easier to understand and maintain.

Perhaps the lack of features was acceptable in the days when only a few skilled programmers dealt with multitasking and shared data. Now, however, the high-level API of OS/2 allows the "average" programmer to exploit these advanced operating system features. In addition, more and more programmers need these features in their applications, whether under OS/2, UNIX, or an embedded system real-time executive.

Recognizing this, Lattice has taken a tentative step towards evolving C so that it can better support multitasking. The company welcomes comments and criticisms, with the hope that this discussion will lead to an enhanced ANSI standard.