What differences are there between a semaphore wait signal and a condition variable wait signal?
Semaphore wait signal:
- They can be used anywhere except in a monitor.
- The wait() function does not always blocks its caller.
- The signal() function increments the semaphore counter and can release a process.
- If the signal() releases a process, the released and the caller both continue.
Condition Variable wait signal:
- It can only be used in monitors.
- The wait() function always blocks its caller.
- The signal() can either release a process or it is lost as if it never occurred.
- On signal() releasing a process either the caller or the released continues but not both at the same time.
For a deadlock to occur what are the necessary conditions
In order for deadlocks to occur there are four necessary conditions:
- Mutual Exclusion: The resources available are not sharable. This implies that the resources used must be mutually exclusive.
- Hold and Wait: Any process requires some resources in order to be executed. In case of insufficient availability of resources a process can take the available resources, hold them and wait for more resources to be available.
- No Preemption: The resources that a process has on hold can only be released by the process itself voluntarily. This resource cannot be preempted by the system.
- Circular Waiting: A special type of waiting in which one process is waiting for the resources held by a second process. The second process is in turn waiting for the resources held by the first process.
Why is the context switch overhead of a user-level threading as compared to the overhead for processes? Explain.
This is due to the reason that a context switch implementation is done by the kernel. During this process the state information is copied between the processor and the PCB (process control block) or the TCB (thread control block).
Since the kernel does not know anything about user-level threads, technically it is not possible for it to be a user level thread context switch. The user level scheduler can do some limited state copying on the behalf of a thread prior to the control being handed to that thread. But this copying of state information is smaller compared to that of a
kernel-level process. Also the process does not involve going into the kernel mode with the help of a system call.
Post a Comment