OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide

conjunction, but in practice, the interpretation of the max_calls_requests parameter is

highly dependent on protocol and implementation.

For example, in a connection-oriented protocol based on Berkeley sockets, the socket

backlog—the number of connections which may be queued on a socket pending

acceptance—typically has a value of ﬁve.

Portable applications should therefore not rely on max_calls_requests as anything more

than a hint to the runtime about the number of queued calls desired. Note well that the

max_call_requests parameter does not set the number of calls that can be handled

concurrently. That is strictly a function of the number of call threads, as speciﬁed by

max_calls_exec. The max_call_requests parameter simply speciﬁes (as a hint) the

number of calls that can be queued prior to being picked up by call threads.

2.1.3 Scheduling Policies

The default thread scheduling policy provides round robin time-slicing and guarantees

that even low priority threads will get to run. For servers, this policy will provide at least

the beneﬁt of fair access to server processing time for multiple callers, even when no real

parallelism is provided by multiple threads of execution.

2.2 Thread Safety

Thread safety involves two issues. The ﬁrst is blocking behavior. Blocking I/O should

block just the thread doing the I/O, not the entire process. The following scenario

illustrates the kind of problem that can occur when an application fails to observe this

rule:

1. The client side of the application executes a blocking I/O call such as a read()

from the keyboard.

2. The read() sleeps for an indeterminate amount of time. All threads in the client

process are blocked.

3. A timer thread in the client RPC runtime, which manages the client side of the

RPC protocol, is among the blocked threads. Eventually the server side times the

connection out, even though the client application is still running.

The second thread safety issue is reentrancy. Routines that operate on shared objects

must have appropriate locking in place. A typical reentrancy problem is as follows:

1. The application invokes a nonreentrant malloc().

2. DCE threads interrupts the malloc( ) and the interrupt handler executes a properly

reentrant malloc( ). The reentrant malloc( ) examines a lock and incorrectly infers

that nobody else is currently doing a malloc( ).

3. Global data governing memory allocation for the process becomes corrupted.

2− 4 Tandem Computers Incorporated 124246