Chapter 11
| 11.1 | A version of the program that allocates the memory dynamically instead of using an automatic variable is shown in Figure C.11.
Figure C.11. Correct use of thread return value
#include "apue.h"
#include <pthread.h>
struct foo {
int a, b, c, d;
};
void
printfoo(const char *s, const struct foo *fp)
{
printf(s);
printf(" structure at 0x%x\n", (unsigned)fp);
printf(" foo.a = %d\n", fp->a);
printf(" foo.b = %d\n", fp->b);
printf(" foo.c = %d\n", fp->c);
printf(" foo.d = %d\n", fp->d);
}
void *
thr_fn1(void *arg)
{
struct foo *fp;
if ((fp = malloc(sizeof(struct foo))) == NULL)
err_sys("can't allocate memory");
fp->a = 1;
fp->b = 2;
fp->c = 3;
fp->d = 4;
printfoo("thread:\n", fp);
return((void *)fp);
}
int
main(void)
{
int err;
pthread_t tid1;
struct foo *fp;
err = pthread_create(&tid1, NULL, thr_fn1, NULL);
if (err != 0)
err_exit(err, "can't create thread 1");
err = pthread_join(tid1, (void *)&fp);
if (err != 0)
err_exit(err, "can't join with thread 1");
printfoo("parent:\n", fp);
exit(0);
}
| | 11.2 | To change the thread ID of a pending job, the readerwriter lock must be held in write mode to prevent anyone from searching the list while the ID is being changed. The problem with the way the interfaces are currently defined is that the ID of a job can change between the time that the job is found with job_find and the job is removed from the list by calling job_remove. This problem can be solved by embedding a reference count and a mutex inside the job structure and having job_find increment the reference count. The code that changes the ID can then avoid any job in the list that has a nonzero reference count. | | 11.3 | First of all, the list is protected by a readerwriter lock, but the condition variable needs a mutex to protect the condition. Second, the condition each thread should wait to be satisfied is that there is a job for it to process, so we need to create a per thread data structure to represent this condition. Alternatively, we can embed the mutex and condition variable in the queue structure, but this means that all worker threads will wait on the same condition. If there are many worker threads, we can run into a thundering herd problem, whereby many threads are awakened without work to do, resulting in a waste of CPU resources and increased lock contention. | | 11.4 | It depends on the circumstances. In general, both can be correct, but each alternative has drawbacks. In the first sequence, the waiting threads will be scheduled to run after we call pthread_cond_broadcast. If the program is running on a multiprocessor, some threads will run and immediately block because we are still holding the mutex (recall that pthread_cond_wait returns with the mutex held). In the second sequence, a running thread can acquire the mutex between steps 3 and 4, invalidate the condition, and release the mutex. Then, when we call pthread_cond_broadcast, the condition will no longer be true, and the threads will run needlessly. This is why the awakened threads must recheck the condition and not assume that it is true merely because pthread_cond_wait returned. |
|
