If thr_join is called with a tid of zero, the calling process will wait for any other thread to call thr_exit, hence the departed argument, so that the calling thread knows which thread's exiting caused it to finish joining. Let's say we have three threads 1,2, and 3. Thread 3 is computing away hapily, and then both thread's 1 and 2 call:

thr_join( 3, departed, status );

where departed and status are variables of the appropriate type. They both must give up the CPU, and wait for 3 to finish. So, let's say that 3 finishes what it was doing and calls thr_exit(), and that immediately afterwords, thread 1 is scheduled. It will see that thread 3 has called thr_exit, and will return successfully with 0, and with the appropriate data in the memory locations pointed to by departed and status. The next time that thread 2 runs, it will see that thread 3 has already been dealt with and will return a negative number, without the appropriate data in the memory locations pointed to by departed and status.

Suppose,now, that both threads 1 and 2 have called thr_join with first argument 0, that thread 3 has just now called thr_exit, and that thread 1 is scheduled following the exiting of thread 3. Also, let's assume that threads 1,2, and 3 are the only threads running in this process. Thread 1 will return from thr_join successfully with departed pointing to an integer with value 3, and status pointing to the return status of thread 3, assuming that departed and status were not passed in as NULL. Thread 2, however, will continue to wait for any other thread to call thr_exit.

Q: For thr_exit(), it says "... and passed in the return value from...". So what is the return value? (the return type for thr_exit is void.)

The return value is the argument passed to thr_exit. It has type void * so that you can return whatever you like. If a thread fails to call thr_exit, and another thread attempts to join on it, the value the joining thread sees upon a successful join in the memory pointed to by its status pointer should be the return value of the function func where func was the function passed to thr_create for the thread that failed to call thr_exit. Try maybe the Solaris or Linux pthread man pages for a different explaination.

Q: What should happen if a mutex or condition variable is used before mutex_init or cond_init? What happens if someone destroys a locked mutex or a condition variable on which someone is waiting?

The behavoir of mutex_lock and mutex_unlock may be undefined before a mutex_init and after a mutex_destroy of the appropriate mutex. The same thing applies to using condition variables, too. Be careful about destruction, though. On destroying a condition variable or mutex all resources must be freed, however if any threads are waiting on the condition variable, or if the mutex is locked, the destruction functions should return an error.

Q: Do we have to prevent (or rather avoid) deadlocks between joining threads? For example thread 1 joins thread 2, thread 2 joins thread 1. And do we have to avoid deadlocks resulting from mutex usage? Like thread one locks mutex1, thread 2 locks mutex2, thread 2 tries to lock mutex1, thread 1 tries to lock mutex2.

Your thread library need not protect against user induced deadlock, as in these examples. Your solutions will not be expected to recover from, prevent, or avoid these situations. The thread library should not, however, be the cause of any deadlock. In the second part of project two, your solutions will be expected to avoid deadlock, but this will not be part of the thread library.

Q: Do I have to worry about shceduling my threads? Do I have to worry about context switching?

Since each thread is associated with an underlying process, you may rely on the kernel to handle these details.