are 'acquire semaphore' nodes served in the order they have executed?

[LuI]

Hi there,

I've got a Q related to semaphores and parallel running VIs.

In my project, several VIs need to share a ressource.  I've encapsuled the problematic code by acquire and release a semaphore that is named for the specific ressource. Say 'DMM', 'FG', 'AckuSrc' ...
Now I need to know in which order calls to 'acquire semaphore' are served.

Imagine a process acquired semaphore DMM. While this is used, some other processes need the DMM as well. They execute 'acquire semaphore' and get stuck in the timeout. When the first process releases DMM, which one of the waiting processes will get it? Is it determined by the order the calls to 'acquire semaphore' took place? Or is it indetermined?

In other words, when a call to 'acquire semaphore' times out, does it make sense to repeat it in the certainty that it finally will get its semaphore. Or can a process 'starve to death' waiting (cause others might always 'snatch it away')?
Multithreading can be quite complicated...

The real problem is in a client-server architecture. When a client that acquired a semaphore got stuck and needs to be killed/resetted, how to free the ressources? When serving to 'acquire semaphore' is deterministic, and a timeout (that is long enough to assure the owner hangs) occured, one can simply release a semaphore before acquiring it.
If 'acquire semaphore' is indetermined, one needs to set up a server functionality that takes care of who acquired a ressource and which client is still operating well. Than one can kill  processes AND their ressources. A lot of extra work, allthough much more straight and reliably ... But sometimes time gets important...

Greetings from Germany!<br>-- <br>Uwe

[ManuelW]

Hello Uwe

I have found this link:

http://digital.ni.com/public.nsf/websearch/D62D6D6DDA4BBAD386256C41005A43AF?OpenDocument

Hope this helps

Manuel

[ryank]

Manuel's KB seems to have answered most of your question.  However, I would like to point one thing out.  In addition to the order in which semaphore requests were served, you were asking about timing out and retrying.  I'm fairly certain that when a semaphore times out, its request is removed from the semaphore request queue (otherwise you would have requests for semaphores that might not be waiting anymore).  Therefore, if a semaphore times out and you restart it, it will get bumped to the back of the line.  Probability is going to protect you from having semaphores starve in this way as long as

A.  The semaphores all have the same timeout values and restart logic.  If one of the semaphores timed out faster than the others it would be more likely to starve as it would be getting bumped to the back of the line more often.

B.  You use relatively long timeouts for your semaphores.  The shorter the timeout period, the more random the semaphore allocation is going to be, and the higher the probability of a thread getting starved.

Hope that helps,

Ryan K.