Releasing-request problem
- /* .. One solution to the releasing-request problem */
- // this is a 'non-releasing' routine requesting releasing
- routine_a()
- {
- mutex_lock(mutex);
- // ...
- mutex_lock(mutex_r);
- flag = 1;
- request(); // notify the releasor
- cond_wait(cond_r, mutex_r);
- flag = 0;
- mutex_unlock(mutex_r);
- // ...
- mutex_unlock(mutex);
- }
- // this is the 'releasing' routine
- routine_b()
- {
- again:
- if (flag)
- {
- mutex_lock(mutex_r);
- // needs to check again if the response is actually wanted (check the flag again)
- if (flag)
- {
- response();
- cond_signal(cond_r);
- mutex_unlock(mutex_r);
- }
- else
- {
- mutex_unlock(mutex_r);
- goto again;
- }
- }
- else
- {
- if (mutex_lock(mutex, timeout) == success) // a timing-out relaxation needed to avoid deadlock
- {
- // common releasing procedure
- mutex_unlock(mutex);
- }
- else
- {
- goto again;
- }
- }
- }
- // this is another 'non-releasing' routine
- routine_c()
- {
- mutex_lock(mutex);
- // ...
- mutex_unlock(mutex);
- }
- /* .. Another way to solve the releasing-request problem */
- // this is a 'non-releasing' routine requesting releasing
- routine_a()
- {
- mutex_lock(mutex);
// disable scheduling until cond_wait is waiting so that the execution of the following code is not interrupted- disable_scheduling(); // to protect critical data
- request(); // notify the releasor (through message)
- flag = 1;
- cond_wait(cond, mutex);
- flag = 0;
- mutex_unlock(mutex);
- }
- // this is the 'releasing' routine
- routine_b()
- {
- again:
- if (flag)
- {
- response();
- cond_signal(cond);
- }
- else
- {
- if (mutex_lock(mutex, timeout) == success) // relaxation
- {
- // common releasing procedure
- // ...
- mutex_unlock(mutex);
- }
- else goto again;
- }
- }
In this problem, one routine acts as a releasing requestor, it notifies another routine by sending a signal and then waits for it to release the resource. On making the request, the mutex is unlocked, so that the routine to perform the releasing in another thread can proceed. However, any other thread that doesn't have this privilege (not to release the resource, just as the requestor itself) should be blocked during this process.
2009.11
Problem description: A mutual exclusive resource R is acquired and released by calling its Acquire and Release method respectively. The calling methods can reside in different threads.
These two methods should offer a proper mechanism to manage clients' accessing and using this resource.
A solution so far that is deemed able to address all formerly existing problems: