many to one notification

[Siamak]

How about incrementing one shared variable once by each of Many VIs, and decrementing it at meeting point by each of Many (occures only once). The main VI checks upon this SV if it is zero. This suits dynamic programming more than few other ideas.

My points is either of these ideas, whichever more flexible and effective, can fit in one other standard VI in LV by NI.

Cheers,

Sia

[MikeS81]

---

Siamak wrote:

How about incrementing one shared variable once by each of Many VIs, and decrementing it at meeting point by each of Many (occures only once). The main VI checks upon this SV if it is zero. This suits dynamic programming more than few other ideas.

My points is either of these ideas, whichever more flexible and effective, can fit in one other standard VI in LV by NI.

Cheers,

Sia

---

Hi Siamak,

how would you know, that not two functions write at the same time to the shared variable?

Mike

[Broken_Arrow]

Your original question can be answered (and has) by just about any of the hard-to-spell functions on the Synchronization pallette...

---

Siamak wrote:

Hi,

...... so that one VI has to wait until several other VIs meet a certain point and continue.

---

... I think we've discussed them all except Occurrences. Imagine these loops are VI's. When the "certain points" of 222, 333, and 444 are met, the loop on the right starts.

[F._Schubert]

Shared variables are a bad choice. Benchmarks show much better performances with the following options: Globals, LV2 Functional Globals (or Action Engines) and Single Element Queues. I wouldn't use Globals due to the risk of race conditions.

So you might be polling LV2FGV or SEQs, but the big thing of the syncronization VIs is, that they call asyncronous.

You can simply transform a LV2FGV into a powerful action engine that does send a notification once the count comes down to zero. (My favourite solution so far).

One of the syncronization things we didn't metion yet is a semaphore (called mutex in most languages). The behaviour you want is actually just an inversionof a semaphore. Only if all senders have aquired the semaphore, the receiver can run.

As far as I know, semaphores in newer LV versions are based on queues and you might have access to the code. So propably you might come up with the inversion by modifying these.

As a sidenote: you might find a book in the web that has a long list of exersises (including solutions) where a number of sycronization issues is solved with semaphores (they are called mutex there) and rendevouz. The author comes from a OS background (as far as I remember), so these two are the primitives there.

If you still have time and fun playing on that topic, try to solve the puzzels in a LVish way just using queues.

Felix

[Siamak]

Almost every reply has a useful point in it, but still I am not sure if they can be implemented in my architecture;

Broken Arrows solution; does that suit a dynamic number of 'many' VIs? plus the fact that the 'one' VI runs first (it actually launches 'many' VIs), so can it have a reference to the occurance back into itself?

Mike, I thought an SV is controllable for writing clashes using Single Writer flag when Network Published.

After all of this, my suggestion remains as NI can do a standard set of synch. functions removing worriness and really suitable for this very basic need.

Cheers all,

Sia

Message Edited by Siamak on 08-26-2009 06:11 AM

[MikeS81]

Hi Sia,

why shouldn't it be possible to implement it into your architecture. You need only two vi's. One to send the command and one which receives the send commands. With the queue solution you can have as much parallel running processes as you need and you can synchronise them all.

I see no problem with it and i think we shouldn't call for a new integrated function for all the small problems.

Mike