|
| 以 PDF 格式下载本书 (645 KB)
Chapter 6 Safe and Unsafe InterfacesThis chapter defines MT-safety levels for functions and libraries. Thread SafetyThread safety is the avoidance of data races--situations in which data are set to either correct or incorrect values, depending upon the order in which multiple threads access and modify the data. When no sharing is intended, give each thread a private copy of the data. When sharing is important, provide explicit synchronization to make certain that the program behaves in a deterministic manner. A procedure is thread safe when it is logically correct when executed simultaneously by several threads. At a practical level, it is convenient to recognize three levels of safety.
An unsafe procedure can be made thread safe and serializable by surrounding it with statements to lock and unlock a mutex. Example 6-1shows three simplified implementations of fputs(), initially thread unsafe. Next is a serializable version of this routine with a single mutex protecting the procedure from concurrent execution problems. Actually, this is stronger synchronization than is usually necessary. When two threads are sending output to different files using fputs(), one need not wait for the other--the threads need synchronization only when they are sharing an output file. The last version is MT-safe. It uses one lock for each file, allowing two threads to print to different files at the same time. So, a routine is MT-safe when it is thread safe and its execution does not negatively affect performance. Example 6-1 Degrees of Thread Safety/* not thread-safe */
fputs(const char *s, FILE *stream) {
char *p;
for (p=s; *p; p++)
putc((int)*p, stream);
}
/* serializable */
fputs(const char *s, FILE *stream) {
static mutex_t mut;
char *p;
mutex_lock(&m);
for (p=s; *p; p++)
putc((int)*p, stream);
mutex_unlock(&m);
}
/* MT-Safe */
mutex_t m[NFILE];
fputs(const char *s, FILE *stream) {
static mutex_t mut;
char *p;
mutex_lock(&m[fileno(stream)]);
for (p=s; *p; p++)
putc((int)*p, stream);
mutex_unlock(&m[fileno(stream)]0;
}
MT Interface Safety LevelsThe man Pages(3): Library Routines use the following categories to describe how well an interface supports threads (these categories are explained more fully in the Intro(3) reference manual page).
See the table in Appendix C, MT Safety Levels: Library Interfaces,; for the safety levels of interfaces from the man Pages(3): Library Routines. Check the man page to be sure of the level. Some functions have purposely not been made safe for the following reasons.
There is no way to be certain that a function whose name does not end in "_r" is MT-Safe other than by checking its reference manual page. Use of a function identified as not MT-Safe must be protected by a synchronizing device or by restriction to the initial thread. Reentrant Functions for Unsafe InterfacesFor most functions with Unsafe interfaces, an MT-Safe version of the routine exists. The name of the new MT-Safe routine is always the name of the old Unsafe routine with "_r" appended. The Table 6-1 "_r" routines are supplied in the Solaris system. Table 6-1 Reentrant Functions
Async-Signal-Safe FunctionsFunctions that can safely be called from signal handlers are Async-Signal-Safe. The POSIX standard defines and lists Async-Signal-Safe functions (IEEE Std 1003.1-1990, 3.3.1.3 (3)(f), page 55). In addition to the POSIX Async-Signal-Safe functions, these three functions from the Solaris threads library are also Async- Signal-Safe. MT Safety Levels for LibrariesAll routines that can potentially be called by a thread from a multithreaded program should be MT-Safe. This means that two or more activations of a routine must be able to correctly execute concurrently. So, every library interface that a multithreaded program uses must be MT-Safe. Not all libraries are now MT-Safe. The commonly used libraries that are MT-Safe are listed in Table 6-2. Additional libraries will eventually be modified to be MT-Safe. Table 6-2 Some MT-Safe Libraries
Unsafe LibrariesRoutines in libraries that are not guaranteed to be MT-Safe can safely be called by multithreaded programs only when such calls are single-threaded. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||