Question

What happens if we dont use semaphore example?

Answer 1

Semaphores Since all threads run in the same address space, they all have access to the same data and variables. If two threads simultaneously attempt to update a global counter variable, it is possible for their operations to interleave in such way that the global state is not correctly modified. Although such a case may only arise only one time out of thousands, a concurrent program needs to coordinate the activities of multiple threads using something more reliable that just depending on the fact that such interference is rare. The semaphore is designed for just this purpose. A semaphore is somewhat like an integer variable, but is special in that its operations (increment and decrement) are guaranteed to be atomic—you cannot be halfway through incrementing the semaphore and be interrupted and waylaid by another thread trying to do the same thing. That means you can increment and decrement the semaphore from multiple threads without interference. By convention, when a semaphore is zero it is "locked" or "in use". Otherwise, positive values indicate that the semaphore is available. A semaphore will never have a negative value. Semaphores are also specifically designed to support an efficient waiting mechanism. If a thread can’t proceed until some change occurs, it is undesirable for that thread to be looping and repeatedly checking the state until it changes. In this case semaphore can be used to represent the right of a thread to proceed. A non-zero value means the thread should continue, zero means to hold off. When a thread attempts to decrement a unavailable semaphore (with a zero value), it efficiently waits until another thread increments the semaphore to signal the state change that will allow it to proceed. Semaphores are usually provided as an ADT by a machine-specific package. As with any ADT, you should only manipulate the variables through the interface routines—in this case SemaphoreWait and SemaphoreSignal below. There is no single standard thread synchronization facility, but they all look and act pretty similarly. SemaphoreWait(Semaphore s) If a semaphore value is positive, decrement the value otherwise suspend the thread and block on that semaphore until it becomes positive. The thread package keeps track of the threads that are blocked on a particular semaphore. Many packages guarantee FIFO/queue behavior for the unblocking of threads to avoid starvation. Alternately the threads blocked on a semaphore may be stored as a set where the thread manager is free to choose any one. In that case, a thread could theoretically starve, but it's unlikely
Reader-Writer example In this classic Reader-Writer problem, there are two threads exchanging information through a fixed size buffer. The Writer thread fills the buffer with data whenever there's room for more. The Reader thread reads data from the buffer and prints it. Both threads have a situation where they should block. The writer blocks when the buffer is full and the reader blocks when the buffer is empty. The problem is to get them to cooperate nicely and block efficiently when necessary. For this problem, we will use "generalized semaphores" where the value can be any nonnegative number. Zero still means "locked" and any other value means "available". The code cannot look at the value of a generalized semaphore explicitly, you can only call SemaphoreWait and SemaphoreSignal which in turn depend on the value.