Thread locking. This exercise asks you write a threaded program that deadlocks using mutex locks. You will be able to reuse a lot of the Assignment 8 code. The text gives us fair warning that a threaded application in which one thread locks a first mutex and then locks a second mutex will eventually come a cropper (i. e., deadlock) with another thread that locks the same mutexes in reverse order. Given the vagaries of the scheduler, inducing the deadlock condition may take more than 2 threads. You are strongly advised to write the pseudocode BEFORE writing the code! Before submitting your program you also should reread this problem description to make sure you addressed every point. As the mutex locks must be available to the main routine and the threads for this exercise you are allowed to declare the 2 variables of type pthread_mutex_t as global variables. As in Assignment 8, this program takes one command line parameter: the number of threads to create. Each thread created must be passed an argument with its thread number: 1, 2, 3, If the thread number is even, the thread should lock the 2 mutexes in one order; and, if the thread number is odd, it should lock the 2 mutexes in reverse order. After locking the two mutexes, each thread must sleep for the number of seconds in its passed argument (i. e., its thread number), and then must unlock the mutexes in the order that is the reverse of the locking order. (Note: this sleep is necessary to induce the deadlock; threads should NEVER sleep when holding locks!) The main routine is charged with detecting the deadlock condition, and this algorithm is a little tricky because Linux and BSD systems differ from MACs in the behavior of the pthread_mutex_trylock(3) function. On the MACs the trylock function returns ETIMEDOUT (errno = 60) when a call to the trylock function would block because the lock is not available; Linux and BSD systems return EBUSY (errno = 16). In the main routine the following pthread functions should be checked for success/failure, and if the call fails, perror should be called and the exit(3) should be called: pthread_mutex_init(3) pthread_create(3). In the main routine the following functions should call perror on error, but NOT call exit: pthread_mutex_trylock(3) pthread_mutex_unlock(3). In the main routine the following function does NOT need to be checked for an error return (but, this function must be called for every mutex created BEFORE exiting the main routine): pthread_mutex_destroy(3). In the thread function (only one is required) the following pthread functions should be checked for success/failure, and if the call fails, the thread should call perror, and then pthread_exit(3) with the passed argument as the exit status: pthread_mutex_lock(3) pthread_mutex_unlock(3). The main routine does not have to wait for the exit of each thread (as it would never occur if 2 threads were deadlocked) using pthread_join(3). Instead, the main routine is charged with detecting the deadlock condition. (It is necessary to only call the trylock function for one of the two locks -- why is that?) To do this main must call pthread_try_lock(3) after first sleeping 5 seconds, and then every 5 seconds (altogether once for each thread started). If the trylock returns success the main routine should immediately unlock the mutex. If the trylock call fails, then a count of the number of failures should be incremented. At the end, if the number of failures equals the number of thread created, then the main routine should declare a deadlock has occurred. Here is some sample output (the 60 shown is the errno of ETIMEDOUT on a MAC): rcm$ ass09 3 Main: thread 1 created Thread 1, pid 40213, tid 4489601024 Main: thread 2 created Thread 1, lock1 locked Thread 2, pid 40213, tid 4490137600 Main: thread 3 created Thread 3, pid 40213, tid 4490674176 Thread 1, lock2 locked Thread 1, lock2 unlocked Thread 1, lock1 unlocked Thread 2, lock2 locked Thread 3, lock1 locked trylock: Operation timed out Possible deadlock detected at 5 seconds (60) trylock: Operation timed out Possible deadlock detected at 10 seconds (60) trylock: Operation timed out Possible deadlock detected at 15 seconds (60) Trylock attempts that failed: 3 Deadlock detected