Implement a Semaphores with bounding waiting time - TestAndSet / While loop constantly check for a lock.

Keeps CPU busy. Called "Busy Waiting". Your process is still executing on the CPU eating up the CPU and is not in the wait state NOT GOOD - Unlike Mutex, Semaphore provides access to more than 1 process to critical region. Semaphore is an integer variable accessed through wait() and signal().For implementation Semaphore is a structure that contains 2 things integer value and list of processes. 2 calls tht operating system calls that are provided blocked(), wakeup(process that you want to wake up). IN wait we always write wait(semaphore * S) { S->value -- ; if ( S --> value < 0) { Add this process to S -->list; block(); } } In signal we write signal (Semaphore * S) { S--> value ++; if (S --> value <=0) { remove the process P from the S-->list ; wakeup(P); } } Mutex spin lock with test and set to lock or unlock intTEstAndSet(int m) { Intrv=m; M=1; Return rv } Int m m.lock() { // Critical section; Test&set (m); } m.unlock(); int mutex=0 lock( mutex) { while (TESTANDSET(MUTEX,1)==1 } //to unlock Unlock (MUTEX) { mutex=0; }

Bounded Waiting Time Once a process P has made a request to enter its critical section, the number of other process (or threads) that are allowed to access the shared data before P must be bounded. Semaphores Wait() Signal() solution does have a queue/list of processes that are waiting on a semaphore there no problem of starvation. Bounded Buffer Producer / Consumer Rucha will draw the diagram Semaphores VS Condition Variables Can be used anywhere in a program, but should not be used in a monitor Can only be used in monitors Wait() does not always block the caller (i.e., when the semaphore counter is greater than zero). Wait() always blocks the caller. Signal() either releases a blocked thread, if there is one, or increases the semaphore counter. Signal() either releases a blocked thread, if there is one, or the signal is lost as if it never happens. If Signal() releases a blocked thread, the caller and the released thread both continue. If Signal() releases a blocked thread, the caller yields the monitor (Hoare type) or continues (Mesa Type). Only one of the caller or the released thread can continue, but not both.

Lost/Wakup bug If a process invokes a signal() and no other process is waiting then the signal gets lost. Similarly a process can execute a Wait() after the other process executed signal() that was lost. THis is lost wake-up bug Test & Set you can get the current value of mutex and see if its 0 & say someone else goes they do test & set and make it to 1.So you have to make sure that when a person gets a value whn it is 1. since the mutex is shared memory and if it s inconsistant the programmers will have a terrible time to debug this kind of code . soln to bounded waiting problem for lock no because if you want shared mutex and you have a long critical section The interrupt is detected before the next program instruction is fetched, and the hardware saves the state of the process on the stack (just like in any subroutine call), the address of the ISR (interrupt service routine) is found in the interrupt vector according to the interrupt type number), that address is loaded into the PC and we branch to that routine, which is of course running in kernel mode. Now it handles the interrupt. In most cases this is for I/O completion. In this case it unblocks (places the PCB on ready Queue) the process waiting on that I/O (if any) and if any I/O requests for that device are enQueued on the waiting Queue for that device it starts the next I/O. Since disks are shared devices and only one request is handled at a time, there is usually a Queue of requests for that device awaiting their chance. Now, as I said above, in most cases an expensive context switch is not required, and so the Stack is popped and the state of the user process is restored. Just like returning from any function call, except now we are also returned to user mode. In the several cases above where a context switch is required, then the scheduler would be invoked to do so.