10 {
11 char *pointer;
12
13 flockfile (stdout);
14 for (pointer = arg; *pointer != ' '; pointer++) {
15 putchar_unlocked (*pointer);
16 sleep (1);
17 }
18 funlockfile (stdout);
19 return NULL;
20 }
21
22 /*
23 * This function writes a string (the function's arg) to stdout,
24 * by using putchar to write each character individually.
25 * Although the internal locking of putchar prevents file stream
26 * corruption, the writes of various threads may be interleaved.
27 */
28 void *unlock_routine (void *arg)
29 {
30 char *pointer;
31
32 for (pointer = arg; *pointer != ' '; pointer++) {
33 putchar (*pointer);
34 sleep (1);
35 }
36 return NULL;
37 }
38
39 int main (int argc, char *argv[])
40 {
41 pthread_t thread1, thread2, thread3;
42 int flock_flag = 1;
43 void *(*thread_func)(void *);
44 int status;
45
46 if (argc > 1)
47 flock_flag = atoi (argv[l]);
48 if (flock_flag)
49 thread_func = lock_routine;
50 else
51 thread_func = unlock_routine;
52 status = pthread_create (
53 &thread1, NULL, thread_func, 'this is thread 1
');
54 if (status != 0)
55 err_abort (status, 'Create thread');
56 status = pthread_create (
57 &thread2, NULL, thread_func, 'this is thread 2
');
58 if (status != 0)
59 err_abort (status, 'Create thread');
60 status = pthread_create (
61 &thread3, NULL, thread_func, 'this is thread 3
');
62 if (status != 0)
63 err_abort (status, 'Create thread');
64 pthread_exit (NULL);
65 }
6.5 Thread-safe functions
Although ANSI C and POSIX 1003.1-1990 were not developed with threads in mind, most of the functions they define can be made thread-safe without changing the external interface. For example, although malloc and free must be changed to support threads, code calling these functions need not be aware of the changes. When you call malloc, it locks a mutex (or perhaps several mutexes) to perform the operation, or may use other equivalent synchronization mechanisms. But your code just calls malloc as it always has, and it does the same thing as always.
In two main classes of functions, this is not true:
• Functions that traditionally return pointers to internal static buffers, for example, asctime. An internal mutex wouldn't help, since the caller will read the formatted time string some time after the function returns and, therefore, after the mutex has been unlocked.
• Functions that require static context between a series of calls, for example, strtok, which stores the current position within the token string in a local static variable. Again, using a mutex within strtok wouldn't help, because other threads would be able to overwrite the current location between two calls.
In these cases, Pthreads has defined variants of the existing functions that are thread-safe, which are designated by the suffix '_r' at the end of the function name. These variants move context outside the library, under the caller's control. When each thread uses a private buffer or context, the functions are thread-safe. You can also share context between threads if you want — but the caller must provide synchronization between the threads. If you want two threads to search a directory in parallel, you must synchronize their use of the shared struct dirent passed to readdir_r.
A few existing functions, such as ctermid, are already thread-safe as long as certain restrictions are placed on parameters. These restrictions are noted in the following sections.
6.5.1 User and terminal identification
int getlogin_r (char *name, size_t namesize);
char *ctermid (char *s);
int ttyname_r (int fildes, char *name, size_t namesize);
These functions return data to a caller-specified buffer. For getlogin_r, namesize must be at least LOGIN_NAME_MAX characters. For ttyname_r, namesize must be at least TTY_NAME_MAX characters. Either function returns a value of 0 on success, or an error number on failure. In addition to errors that might be returned by getlogin or ttyname, getlogin_r and ttyname_r may return ERANGE to indicate that the name buffer is too small.
Pthreads requires that when ctermid (which has not changed) is used in a threaded
