Would anybody explain these few Synchronisation Techniques?

[zeus]

Bon Sieur,

I'm doing a research on these 3 Synchronisation Techniques, namely; Notifiers, Occurences, Semaphores.
Frankly, it seems to me that all of them does the same thing, but surely these functions are unique and be useful in certain circumstances in some way or another. If anybody can contribute any simple materials that explain their differences (comparisons), example VIs or links that i could refer to, it would be very much appreciated. Thanks ...... 🙂

[JeremyB]

There are are a number of pages on the NI web site that can help understand the concept of notifiers, occurrences and semaphores. Some links you might like to look at are as follows:

Notifiers:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/b9398355d9550eaf862566f20009de19?OpenDocument

Occurrences:
http://zone.ni.com/devzone/conceptd.nsf/webmain/7A8C9EB57C8982BE86256802007B99A3?OpenDocument
Semaphores:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/a1ba7477550dbfde862565bc006cd410?OpenDocument

To summarize some of the information given on the pages linked above:

1. Notifiers generally act as a mailbox for two separate parts of your application. One part of your app posts data into the mailbox/notifier while the other part of the app can retrieve this data once it has been posted.

Notifiers cannot be used across an applications running across a network or across VI Server.

They work in a similar manner to local/global variables with the exception that the part of the application waiting for the data to be posted does not have to wait polling the notifier in a loop (unlike repetitively polling a local/global variable). The part of the application waiting for the notifier will stop executing completely until the data is posted.

2. Semaphores are used to stop two or more sections of an application being run concurrently. An example may be where two sections of the application are trying to communicate with a single instrument. Both sections of the software cannot communicate with the instrument at the same time and so the section of software that reaches the critical section first acquires the semaphore. It then completes the critical section of code i.e. the communication with the instrument and then releases the semaphore. The other section of code must wait until the semaphore has been released before it is allowed to enter the critical section and communicate with the instrument.

Think of a semaphore as a token and that you can't perform a task unless you have the token. Once you have finished with the token you must release the token so that somebody else can perform their tasks.

3. Occurrences work in a similar fashion to notifiers with the exception that an occurrence is basically a trigger generated by one part of your application and received by another part of your application. In the same way with notifiers, waiting for an occurrence has considerably less overhead compared to polling for a local/global variable. Occurrences can also be generated by the hardware you are using (for example a data acquisition board) when a particular condition occurs.

Examples are supplied with LabVIEW of all of the above and can be found in the following folder:

..Examples\General\synchexm.llb or if you are using LabVIEW 6.1 you can search through the examples by function. Further examples can be found on Developer Zone and ni.com/support

Jeremy