Fig. 10-7. Selected template calls.
The attr_create and attr_delete calls create and delete thread templates, respectively. Other calls allow programs to read and write the template's attributes, such as the stack size and scheduling parameters to be used for threads created with the template. Similarly, calls are provided to create and delete templates for mutexes and condition variables. The need for the latter is not entirely obvious, since they have no attributes and no operations. Perhaps, the designers were hoping that someone would one day think of an attribute.
The third group deals with mutexes, which can be created and destroyed dynamically. Three operations are defined on mutexes, as shown in Fig. 10-8. The operations are for locking, unlocking mutexes, and for trying but accepting failure if locking cannot be done.
| Call | Description |
|---|---|
| Mutex_init | Create a mutex |
| Mutex_destroy | Delete a mutex |
| Mutex_lock | Try to lock a mutex; if it is already locked, block |
| Mutex_trylock | Try to lock a mutex; fail if it is already locked |
| Mutex_unlock | Unlock a mutex |
Fig. 10-8. Selected mutex calls.
Next come the calls relating to condition variables, listed in Fig. 10-9. Condition variables, too, can be created and destroyed dynamically. Threads can sleep on condition variables pending the availability of some needed resource. Two wakeup operations are provided: signaling, which wakes up exactly one waiting thread, and broadcasting, which wakes them all up.
| Call | Description |
|---|---|
| Cond_init | Create a condition variable |
| Cond_destroy | Delete a condition variable |
| Cond_wait | Wait on a condition variable until a signal or broadcast arrives |
| Cond_signal | Wake up at most one thread waiting on the condition variable |
| Cond_broadcast | Wake up all the threads waiting on the condition variable |
Fig. 10-9. Selected condition variable calls.
Figure 10-10 lists the three calls for manipulating per-thread global variables. These are variables that may be used by any procedure in the thread that created them, but which are invisible to other threads. The concept of a per-thread global variable is not supported by any of the popular programming languages, so they have to be managed at run time. The first call creates an identifier and allocates storage, the second assigns a pointer to a per-thread global variable, and the third allows the thread to read back a per-thread global variable value. Many computer scientists consider global variables to be in the same league as that all-time great pariah, the GOTO statement, so they would no doubt rejoice at the idea of making them cumbersome to use. (The author once tried to design a programming language with a
IKNOWTHISISASTUPIDTHINGTODOBUTNEVERTHELESSGOTO LABEL;
statement, but was forcibly restrained from doing so by his colleagues.) It can be argued that having per-thread global variables use procedure calls instead of language scoping rules, like locals and globals, is an emergency measure introduced simply because most programming languages do not allow the concept to be expressed syntactically.
| Call | Description |
|---|---|
| Keycreate | Create a global variable for this thread |
| Setspecific | Assign a pointer value to a per-thred global variable |
| Getspecific | Read a pointer value from a per-thread global variable |
Fig. 10-10. Selected per-thread global variable calls.
The next group of calls (see Fig. 10-11) deals with killing threads and the threads' ability to resist. The cancel call tries to kill a thread, but sometimes killing a thread can have devastating effects, for example, if the thread has a mutex locked at the time. For this reason, threads can arrange for attempts to kill them to be enabled or disabled in various ways, very roughly analogous to the ability of UNIX processes to catch or ignore signals instead of being terminated by them.
| Call | Description |
|---|---|
| Cancel | Try to kill another thread |
| Setcancel | Enable or disable ability of other threads to kill this thread |
Fig. 10-11. Selected calls relating to killing threads.
Finally, our last group (see Fig. 10-12) is concerned with scheduling. The package allows the threads in a process to be scheduled according to FIFO, round robin, preemptive, nonpreemptive, and other algorithms. By using these calls, the algorithm and priorities can be set. The system works best if threads do not elect to be scheduled with conflicting algorithms.
| Call | Description |
|---|---|
| Setscheduler | Set the scheduling algorithm |
| Getscheduler | Read the current scheduling algorithm |
| Setprio | Set the scheduling priority |
| Getprio | Get the current scheduling priority |
Fig. 10-12. Selected scheduling calls.
10.3. REMOTE PROCEDURE CALL
DCE is based on the client/server model. Clients request services by making remote procedure calls to distant servers. In this section we will describe how this mechanism appears to both sides and how it is implemented.
10.3.1. Goals of DCE RPC
The goals of the DCE RPC system are relatively traditional. First and foremost, the RPC system makes it possible for a client to access a remote service by simply calling a local procedure. This interface makes it possible for client (i.e., application) programs to be written in a simple way, familiar to most programmers. It also makes it easy to have large volumes of existing code run in a distributed environment with few, if any, changes.