2

Semaphores are an abstract mechanism to control access to a shared resource. Other such mechanisms exist, for example locks and monitors. These are the counterparts of abstract data structures – they specify an API for a mechanism and its semantics, but not its implementation. Implementing such mechanisms correctly requires hardware support. One way to ...


1

my answer to the first problem would go like this: From a logical perspective, it depends on the actual purpose of the application, however, we should at least ensure safety and liveness, therefore some locking algorithms are appropriate. Since the contest could be very serious (legal consequences in case of booking failure) I would opt for a mutual ...


1

When using semaphores or locks, you don't do anything else than acquiring the semaphore (resp. the lock), and then do what you want. For example, if you want to use a lock, then you typically have two threads # thread 1 lock.acquire() # here is all the work for thread 1 lock.release() and the other thread is completely identical: # thread 2 lock.acquire()...


1

The semaphore doesn't issue those. A semaphore is an object that can be used by processes to coordinate between themselves. Thus, a process will call semSignal or semWait on a shared semaphore. We can't describe the conditions under which it will do that in general, because it's up to each process how it wants to use semaphores. Semaphores are a ...


1

If only one semaphore is used to control the access to the critical section, it is not possible for deadlock to happen. That is why two semaphores are used in the problem statement since the problem is designed to, I assume, showcase deadlock. A single-semaphore-based program can protect the critical section from concurrent access as well, as demonstrated ...


Only top voted, non community-wiki answers of a minimum length are eligible