Synchronization: Semaphores

[SercoSteveB]

Which of the following is/are TRUE regarding Semaphores?

a) A Semaphore can be used to limit the number of tasks that can simultaneously operate on a shared resource.

b) Semaphores are an indication that a user action has occurred.

c) Each task that reaches a Semaphore waits until the specified number of tasks are waiting at which point execution continues.

d) A Semaphore is generated each time the UI thread is accessed.

[ambaum01]

a

[crossrulz]

A

[Asha_Nagaraj]

Ans:- A

[mini09]

Have not worked on semaphores yet would be happy if you post a set of questions from semaphores?

[crossrulz]

To be honest, it's hard to find an actual reason to use semaphores.  Using non-reentrant subVIs does the job in any situation I've been in.

[SercoSteveB]

I would always go SubVI before Semaphore (easier implementation and more readable).  I have no experience of using Semaphores in applications where you are forced to be reentrant (if using recursion for example).  Not even sure if you can use Semaphores in that situation.

[2verb]

Sometimes you don't have the luxury of pulling all accesses of a resource into one VI. The main time this is true is with legacy code. In other words someone wrote the code such that a resource is shared sloppily in several places. Putting semaphores in key sections may make more sense then refactoring. I have had to do this a couple of times.

[SercoSteveB]

Hi 2verb and welcome to The Daily CLAD.  Interesting point; can you expand a little, maybe show an example, I am struggling to see why semaphores would be preferable?

[2verb]

In the cases where I have used them, three things were true. It was a large project. At least some of the data structures were poorly encapsulated. The company was either highly risk averse or highly sensitive to time.

Where I work we have a custom calculator. An operator can enter a formula which will be evaluated twice a second against streaming data. An example use would be to calculate fuel consumption of your car based on readings from the OBD II connector.

The formulas can be saved and transferred to other systems. You can use one formula inside of another and so on.

The data behind this was poorly encapsulated. The main data structure was kept in a VIG. To change it, say by adding a formula, you got the data out of the VIG (and out of the non-reentrant encapsulation) modified it and wrote it back. (Note to new developers. Don't do this! This is a race condition waiting to happen, particularly if there are a lot of parallel loops calling your functions.)

The data structure in question was touched this way in about a dozen places. Even so, it worked fine for many years with occasional mysterious failures we were never able to debug. Once we got a system with hundreds of formulas, the mysterious failures became repeatable. The cause of needing to support so many formulas at once was a new feature highly anticipated by upper management and customers alike. (So we have both time sensitivity and risk aversion.)

I would like to rewrite this section to use a functional global. OOP fans might prefer classes and objects. But I need to weigh the time it will take to convert the functions as they are to functional globals and the risk that I will break something as I change a dozen functions in the heart of a critical system.

Or I can encapsulate the data using a semaphore. The time it takes to do this is the same time as putting two VIs in each of the functions that works with the at risk data structure. The coding change is about as minimal as it gets so the risk of breaking something is likewise minimal.

Since this is what semaphores are for, limiting access to a shared resource, this isn't a band-aid. We can leave it like this, or come back later to refactor when time is not an issue.

To sum up, If I were coding from scratch or had plenty of time, I would refactor to have code use one access point to a limited resource. I would protect this access point with a non-reentrant functional global. If I can't do this, then a semaphore makes sense.

[SercoSteveB]

Awesome explanation 2verb, thanks.  I see what you mean and this is something I will give more thought to using in the future

.

[SercoSteveB]

Answer: A.  Nice one ambaum01, crossrulz, Asha_Nagaraj & 2verb