semaphore vs notifier

[washburn]

Hello all,

I was told this was the correct forum for this mssg.

Please excuse my ignorance, I am a hardware guy and very new to Labview.  I conceptually cannot understand the difference (after going through the tutorial) between the two aforementioned subjects.  It appears to me that a notifier holds a task from performing until it sends notification to that task and the task rcvs it, but isn't this the same thing a semaphore is doing??  In essence the notifier is locking out the task from performing until it receives the notification.

thanks for the response

Washburn

[falkpl]

Semaphores and notifiers are similar in that they are both synchronization mechanishm for concurent programming but they are not exactlt the same.

A semaphor is like a lock, it has no data passing associated with it, but can be used to limit the number of tasks which can access a resource at once.  A notifier is blocking mechanism which does have a datatype associated with it.  To furthur confuse you there are also Queues Rendezvous and Occurances.  What do you need to do with synchronization? 

[washburn]

Paul,

Thanks for the reply.  It is as I thought, that is to say one passes data and the other doesn't.  I understand queue's, but have not looked into rendezvous or occurances yet.  I am not trying to synchronize any specific application only trying to learn labview and familiarize myself with coding with graphical objects.  Once again thanks!

Steve

[falkpl]

In addition to Notifiers passing data, semaphores have a count associated with it.  They are each have their place.  A semephore is good for blocking a limited resource kind of like a maximum occupancy.  Imagine a restaurant with room for 50, if you want to eat there and there are less than 50 people in the room you can enter (less than max count), if the room is full, you must wait (on the semaphor queue) until some one leaves (and when they leave they release a semaphore thus decrementing the count) and the first one on line is let in.  A notifier is a little different, it blocks and waits for notification with a possible message, I dont think typically Notifiers have a size associated with it, that is you wait for a single notification (although it is possible to wait for multiple different notifiers).  this is more akin to going to the same restaurant and when the tables are full the hostess issues a buzzer (you notifier), and wou will wait for it to go off, No Line to wait in.  Both mechanisms can be used to acomplish the same end result.  Synchronization and concurent programming is a very confusing topic.

[RavensFan]

I would probably add one more slight addition to the description of the two.  A notifier has a kind of one way association with the notification.  Basically one side is sending and is the controlling feature, while there are 1 or more dependent processes.  So in your restaurant example, the hostess is the controlling person while the the people holding the buzzers (the receivers of the notifier) are dependent on the hostess for control.

In the case of a semaphore, all the items are pretty much equivalent to each other and are self regulating.  Any person acquiring the semaphore is allowed to take it (as long as no one else has taken it) and must also release it when done.  This would be more like a 1 seat bathroom in the restaurant.  No one is in control telling who can use the bathroom.  Just who ever gets there first locks the door and uses it,  and is obligated to unlock the door and leave when they are done so the next person (whether they are already there waiting to use or no one is) is able to use it.

[falkpl]

True, when I first learned about semaphores in a concurecy class back in my Comp Sci days the project for implementing a semaphore was a bathroom example.  But it was not a 1 stall bathroom but a 4 stall bathroom, so the semaphore wat set to 4 not 1, a semaphore's size is set so it acts like a counting lock (in many cases the size is 1 and it is just like a mutex).  But you are correct to mention that the user of the semaphore must release it otherwise the system will lockup.

[tbd]

Hi Washburn,

       You hardware guys get all girls.

      I'm not sure if this (lonely) CS junkie is coming at this from a slightly different angle, though, I'd have differentiated Notifier's and Semaphores as serving two distinct puposes, conveying data, and gating program execution.

The notifier conveys data and shares similarity with the Queue and the Occurrance (the Occurrance conveying an Event without data.).

The Semaphore gates execution based on a quorum of members being present - and it closest kin is the Rendezvous! The Semaphore pauses WHILE a quorum is present, the Rendezvous pauses UNTIL a quorum is present.

Thanks for bathroom examples falkpl and Ravens Fan - it never occurred to me to config a semaphore with size > 1 - excellent.