semaphore concept

[mohamed123]

AS far as i understand

( definitions on semaphore found in internet )
1. When you create the semaphore, you can initialize its value to any integer,
but after that the only operations you are allowed to perform are increment
(increase by one) and decrement (decrease by one). You cannot read the
current value of the semaphore.

2. When a thread decrements the semaphore, if the result is negative, the
thread blocks itself and cannot continue until another thread increments
the semaphore.

3. When a thread increments the semaphore, if there are other threads waiting, one of the waiting threads gets unblocked.


from the definitions above

if i have a shared resource ,

1)thread1 accesses it . then m_semVal is increamented to say 1
2)if thread2 tries to access the shared resource, the m_semVal , and when m_semVal is accessed , thread2 sees that the resource is already locked by thread one , so waits.
3) once thread1 finishes , it releases the shared resource . so m_semVal is decreamented to 0
4) after this the thread2 can access the shared resource


is that correct understanding ??? or in step2 , thread2 increases the m_semVal ?

regards

[wildfrog]

1)thread1 accesses it . then m_semVal is increamented to say 1Not quite. When a thread 'enters' a semaphore the value is decremented (the actual value is determined by the thread).

2)if thread2 tries to access the shared resource, the m_semVal , and when m_semVal is accessed , The semaphore is locked when it's count =0 (or if the entering thread tries to decrement the count so that the ending result would be <0).

3) once thread1 finishes , it releases the shared resource . so m_semVal is decreamented to 0You need to explicit 'release' the semaphore, but you can do it from any thread.

4) after this the thread2 can access the shared resourceMultiple thread can 'access' the semphore as long as it's count stays >= 0.

A semaphore is not like a critical secation where threads enter and leave, it more or less a counter, that blocks when it reaches 0.

- petter

[mohamed123]

Thanx for that

Does that mean . semaphore to be defined some thing like a

counter which keeps track of how many threads are accessing it ?

i.e if i say 3 threads may access a shared resource then the initital value must be set to m_Sem = 3

and when ever say thread1 accsses the shared resource , m_sem is decremented by 1

m_Sem = 2 . does that mean that two more threads are on the queue to access the shared resource ?

[TheCPUWizard]

counter which keeps track of how many threads are accessing it ?


No the internal (often non-accessible) counter is how many available accesses there are. When the count is 0 or less, then there are no available accesses, and attempts will block.

[mohamed123]

Hi

Firstly thanyou for your responses
On my furthur research on semaphores i found the following points

Point 1:
The concept is similar to a train signal : The thread which enters/uses a shared resource should set this semaphore (flag) to 1 ( i.,e indicating i m using the resource ) once finished using , the same thread should decreament the value to 0 ( i.e say i m finished with it ) , enabling other threads to use this shared resource. Something like a many trains use a single track , they need to set and reset the signal.

Point 2:
Two types of semaphores exist:
* Binary semaphore : Initial value is set to 1 , when the resource is in use , then accessing thread calls P(S) operation , to decrese it to 0 . When the thread has finished its work on this shared resource , it releases the shared resource with operation V(S) i.e resets the value of semaphore to 1.
* Blocking semaphore : Initial value is set to 0 , the resource is blocked if a thread makes a P(S) and is released only when another thread makes a V(S). This is useful when the order of the threads need to be controlled

Are there are any more types of semaphores

And if any one have something to add , please do

Regards
mohamed123

[JVene]

I'm not sure where your research came from, and I must admit I don't use semaphores that much (I don't find them uniquely applicable to as wide a range of subjects as critical sections and mutexes), but any description that involves just 1 state isn't much different than a mutex.

Obviously you can set a semaphore to 1 if only 1 resource is available. That said, a mutex or critical section does that just about as well, but if memory serves, it is easier to check the count of a semaphore without attempting to lock it. Some implementations of critical sections support a 'try lock' concept, which doesn't block if the lock fails - this could be an application for a semaphore with a count of 1.

I don't find references to semaphores starting with a count of zero and incrementing as a means of calling code coordinating their efforts. I do see semaphores starting at zero and increasing as new resources become available, but that's quite a rare concept. I suppose, for example, that such a construct could be used for client/server rendering or compiling. As new servers come online, the semaphore count of total available machines could increment, indicating new resources are available. As such a resource is called upon to do work, the semaphore count would be decreased by the callling thread/process, released when that's done (incrementing the available count).

Some of these actions can be performed with integers and critical sections, if the subject isn't to be made publicly available to multiple processes. That is, critical sections are typically private to a single process, whereas mutexes and semaphores can be named and accessed from multiple processes.

The semaphore is particularly applicable, therefore, to multiple process designs, because the value of the count is public - a trick to pull off (shared memory of some kind) with any other method.

I suppose there are clever implementations in the use of the semaphore, but keeping it simple helps keep it comprehensible.