Semaphores can best be described as counters used to control access to shared resources by multiple processes. They are most often used as a locking mechanism to prevent processes from accessing a particular resource while another process is performing operations on it.
A semaphore is a protected variable or abstract data type which constitutes the classic method for restricting access to shared resources such as shared memory in a parallel programming environment. A counting semaphore is a counter for a set of available resources, rather than a locked/unlocked flag of a single resource.
A semaphore S is an integer variable that, apart from initialization, is accessed only through two standard atomic operations : wait and signal. These operations were originally termed P(for wait) and V(for signal). The classical definitions of wait and signal are :
wait(S) : while S<=0 do no-op;
S=S-1;
signal(S) : S:= S+1;
Modifications to the integer value of the semaphore in the wait and signal operations must be executed indivisibly.
- Semaphores can be used to deal with the n-process critical- section problem.
- Semaphores can be used to solve various synchronization problems.
A mutex is a binary semaphore (a semaphore with capacity of 1), usually including extra features like ownership, priority inversion protection or recursivity. The differences between mutexes and semaphores are operating system dependent, though mutexes are implemented by specialized and faster routines. Mutexes are meant to be used for mutual exclusion (post/release operation is restricted to thread which called pend/acquire) only and binary semaphores are meant to be used for event notification (post-ability from any thread) and mutual exclusion.
Friday, January 8, 2010
Semaphores
Posted by
Sunflower
at
1/08/2010 11:21:00 PM
0
comments
Labels: Binary Semaphore, Integer, Mutex, Operating Systems, Semaphores, Variable
|
| Subscribe by Email |
|
Tuesday, August 25, 2009
Overview Of Mutual Exclusions in Operating Systems
A way of making sure that if one process is using a shared modifiable data, the other processes will be excluded from doing the same thing.
Formally, while one process executes the shared variable, all other processes desiring to do so at the same time moment should be kept waiting; when that process has finished executing the shared variable, one of the processes waiting; while that process has finished executing the shared variable, one of the processes waiting to do so should be allowed to proceed. In this fashion, each process executing the shared data (variables) excludes all others from doing so simultaneously. This is called Mutual Exclusion.
Mutual exclusion (often abbreviated to mutex) algorithms are used in concurrent programming to avoid the simultaneous use of a common resource, such as a global variable, by pieces of computer code called critical sections. A critical section is a piece of code where a process or thread accesses a common resource. The critical section by itself is not a mechanism or algorithm for mutual exclusion. A program, process, or thread can have critical section in it without any mechanism or algorithm, which implements mutual exclusion.
Examples of such resources are fine-grained flags, counters or queues, used to communicate between code that runs concurrently, such as an application and its interrupt handlers. The problem is acute because a thread can be stopped or started at any time.
How Mutual Exclusion is Done ?
We need to stop the two threads from working on the same data at the same time. The most common way to do this today is by using locks. A lock can be either locked or unlocked. As long as you do not forget to lock or unlock the door, this algorithms guarantees mutual exclusion and protects the so called critical region.
C:
1. omp_set_lock (&my_lock);
2. i++;
3. omp_unset_lock (&my_lock);
Actually, the lock needs to be initialized beforehand and destroyed sometime afterwards as well, but that's not too difficult either.
C:
1. #pragma omp critical
2. {
3. i++;
4. }
Or even simpler, like this:
C:
1. #pragma omp atomic
2. i++;
This basically does the same thing, except you do not need to worry about initialization and destruction of the lock and you cannot forget to unlock the mutex accidentally.
Posted by
Sunflower
at
8/25/2009 07:37:00 PM
0
comments
Labels: Algorithm, Deadlocks, Lock, Mutex, Mutual Exclusions, Unlock
|
| Subscribe by Email |
|