Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

The problem: During the implementation of its new and improved back-office opera

ID: 3599968 • Letter: T

Question

The problem:

During the implementation of its new and improved back-office operating system, XYZ Company finds that the OS lacks mechanisms for the ordered acquisition of synchronization objects. The result is that its web servers are periodically locking up.


Systems administrators are perplexed because the systems show all processes are active using the [ps -ef] command except for the web server process, which appears to be waiting in a call to pthread_mutex_lock(). When they reboot the servers, the problem disappears until the servers get busy and the lock-up occurs again. The business impact of this problem is that XYZ Company customers are unable to access the website to make purchases during peak periods.



The task (there are no pictures for this task, only an explanation is needed):

Recommend a deadlock avoidance approach most suitable for the XYZ Company web server application that is not using an ordered acquisition of mutexes.

Explanation / Answer

Deadlock avoidance is very important to configure the server so that it can operate 24 hours per day, and customers can have easy access to the website to make purchases during peak periods. Deadlocks happen when servers are busy processing number of (multiple) programs at the same time and when certain programs request the same threads(resource).

For example, two production employees start Job 1 and Job 2 that both require Tool t1 and Tool T2. Job holds of Tool t1 and requests Tool t2, however Job 2 already got a hold of Tool t2 and requests Tool t1. Both Job A and Job B are now in wait mode for another tool this analogy where processes need the same threads that are never going to be available because neither process has all of the required threads to execute creates DEADLOCK.

There are algorithms that avoid deadlocks by initially waiting for all of the threads to be available before the process to be get started. Considering above example, Job 1 wouldn't have grabbed Tool t1 until all of the necessary tools and parts were available(like t2 here), then it would grab all of them together. Another way to avoid the deadlock would be to grab the tools and parts one-by-one, but release them back if a specific duration of time has gone by. Perhaps Job 1 has held 3 of 4 tools needed for the job for 10 minutes, so the algorithm can now release them back to the shelf before the deadlock occurs according to the second method.


Waiting for every necessary thread to be available before locking them in the mutex can be problematic because one can't predict the time required and could actually be infinite. As threads enter the mutex (pthread_mutex_lock()) they are locked and when they exit the mutex (pthread_mutex_unlock()) they are unlocked. Once a thread is locked into a mutex it cannot be used elsewhere creating the opportunity for deadlocks. However, if the currently locked threads are in the mutex knowing that all threads are available then the process will finish, unlock, and make those threads available for other processes that are needed to be executed.

Holding and locking threads one-by-one for a predetermined amount of time will stop the deadlock condition because those threads will get released if the rest are not available to use and locked within that time period. Then the process of locking the needed threads can start over.Only one thread may have the mutex locked at any given time. Threads attempting to lock an already locked mutex will block until the thread that owns the mutex unlocks that specefic thread. When the thread unlocks the mutex, the highest-priority thread waiting to lock the mutex will unblock and become the new owner of the mutex. In this way, threads will get into a sequence according to priority-order.

With the "Hold and Wait deadlock avoidance",Job 1 would have held Tool t1 and waited for Tool t2. Since Job 2 was already holding Tool t2 and requesting Tool t1 they would have gotten it to complete their job. Then Job 1 would request and hold all of their tools again until all of them are available to use.