multiple queue implementation.

[Ale914]

Hi all,

i have relaized an implementation of "multiple points queue".

in other words "one enqueuer - multiple dequeuer" .

This is an alpha version so please keep in mind this when you'll find the bugs.

I would like to improove the code mainly the mechanism of registration as "listener" of a queue, so please give me all your feedbacks

Ciao,

Alessandro

[Eugen Graf]

What is to open to see the principle? Do you have an example VI ?

Do you use a "Array-DB" as container for all created queues?

P.S. sorry, I see now two example VIs

Ok, say me please when do you use this?

And if you want, you can look on this http://www.labviewtutorial.eu/download/file.php?id=655

And more complex and more universal this one http://www.labviewtutorial.eu/viewtopic.php?f=19&t=9

Regards, Eugen

[Ale914]

QUOTE (Eugen Graf @ Jul 8 2008, 11:01 AM)

...

Ok, say me please when do you use this?

And if you want, you can look on this http://www.labviewtutorial.eu/download/file.php?id=655

And more complex and more universal this one http://www.labviewtutorial.eu/viewtopic.php?f=19&t=9

Regards, Eugen

I use it when i need to dispatch message around the code from one point to different parallel loop for example suppose a quit message or acquired data to send to datalogger and to data viewer simultaneously

Ciao

[Eugen Graf]

QUOTE (Ale914 @ Jul 9 2008, 09:47 AM)

I use it when i need to dispatch message around the code from one point to different parallel loop for example suppose a quit message or acquired data to send to datalogger and to data viewer simultaneously

Ciao

If it's only this use-case, than you not really need the overhead, you done in our example. It can be much easyer, like in my first suggestion, where you open all needed queues at the begin of the programm, and close all at the end of the programm. So each parallel loop can send to each other, bacause each loop get all queue references as input.

[Ale914]

QUOTE (Eugen Graf @ Jul 9 2008, 03:37 AM)

If it's only this use-case, than you not really need the overhead, you done in our example. It can be much easyer, like in my first suggestion, where you open all needed queues at the begin of the programm, and close all at the end of the programm. So each parallel loop can send to each other, bacause each loop get all queue references as input.

my intent is to hidden the multiple queue registration\duplication in Vis very similar to standard labview queue one's

whit my implementation you can also dinamically add or remove listener on a queue also during sw execution

of corse there are margin of improvement

Ciao

[Norm Kirchner]

You are trying to use a queue for something that it was not intended to do or behave like.

I have a much stronger suggestion to use both queues and another notifier type of operation that is supposed to operate like you wish.

And the net effect is that when the notifier or user event is fired in each of it's respective locations, it enqueues the appropriate state into the machine.

I would also suggest you look at LVx @ http://forums.lavag.org/LVx-Exported-LV-Fu...lity-t9437.html

This demonstrates the process that I am describing as well as adding a great deal of functionality to any program.

In short, don't spend time making a fancy queue strategy when what you want is already in front of you w/ a minor tweak to your architecture.

[LAVA 1.0 Content]

QUOTE (Ale914 @ Jul 10 2008, 10:09 AM)

my intent is to hidden the multiple queue registration\duplication in Vis very similar to standard labview queue one's

whit my implementation you can also dinamically add or remove listener on a queue also during sw execution

of corse there are margin of improvement

Ciao

Hi Alessandro,

How doe the primary queues get killed?

I can see were the secondaries get killed by ther recievers, but not the primary.

I have used another approach for creating and maintianing queues to multiple recievers. It is much more complicated than your approach so I'll only outline how I implemented it (BTW it was inspired by Jim Kring Queues with notifiers design pattern).

1) I have a source of data (like a DAQ process) that pushes a list of its channels along with a queue ref into a functional global.

2) It then forks into multiple loops (threads) to support three tasks.

3) The DAQ task uses a queue to pass new data to the "mail Room".

4) The marketing department watches their in-coming mail (queue ref mentioned in #1) for request from subscribers who want to monitor one of the DAQ channels, and passes those requests to the mail-room (via another queue) to let them knowa about a new subscriber.

5) The mail room takes what it recieves from the DAQ (via queue in step #3) and in-turn queues it up to all subscribers. This is done using queue ref that were supplied when they sent their request to the marketing department.

Were this approach was most helpful was in an application where we were collecting data from about 30 sub-systems and the req's demanded that a user should be able to plot any channel vs time OR vs any other channel.

Take care,

Ben

4) The mail room

[shoneill]

Assuming all the code is on one machine, why not use user events with multiple subscribers registering for the event? In effect it's similar to a notifier but with the ability to work via an event case instead of a function.

Once you register more than once, the event gets passed to EACH of the registrees (is that a real word?).

It gives you essentially a 1..n link, albeit without the Queue (backlog) part.

Sample VI Attached (LV 8.2.1).

Shane.

PS I just realised I forgot to destroy the two user events when the program finishes.... Oops

[Ale914]

QUOTE (Norm Kirchner @ Jul 10 2008, 10:15 AM)

You are trying to use a queue for something that it was not intended to do or behave like.

are you sure? why?

can you suggest me a different way to distribute ordered data accross different loops?

QUOTE

I have a much stronger suggestion to use both queues and another notifier type of operation that is supposed to operate like you wish.

And the net effect is that when the notifier or user event is fired in each of it's respective locations, it enqueues the appropriate state into the machine.

ok this is a sulution but is static, every time i need a new queue end point a need to modify the queue start point

QUOTE

I would also suggest you look at LVx @

http://forums.lavag.org/LVx-Exported-

LV

-Fu...lity-t9437.html

This demonstrates the process that I am describing as well as adding a great deal of functionality to any program.

thank for the link, i'll have a look on this

QUOTE

In short, don't spend time making a fancy queue strategy when what you want is already in front of you w/ a minor tweak to your architecture.

i spend my time as i want, also implementing a fancy queue strategy can be fun

Ciao

[Eugen Graf]

QUOTE (shoneill @ Jul 10 2008, 05:52 PM)

Assuming all the code is on one machine, why not use user events with multiple subscribers registering for the event? In effect it's similar to a notifier but with the ability to work via an event case instead of a function.

Once you register more than once, the event gets passed to EACH of the registrees (is that a real word?).

It gives you essentially a 1..n link, albeit without the Queue (backlog) part.

Sample VI Attached (LV 8.2.1).

Shane.

PS I just realised I forgot to destroy the two user events when the program finishes.... Oops

Yes! But UEs have some disadvantages:

I can't flush UEs

I can't preview UEs

I can't get status of UEs (need count of elements in my programms)

But for this one issue of course it's right alternative.

@Alessandro

My implementation of Client Registration is like yours

QUOTE

So when we open a named queue, we look for a match of that name.

You also check the name of the Queue. Ok, but what will happen if two or more "clients" want to use the same name?

In this case I compare the queue reference number, not the name of the queue. Is it a good sugesstion to improve your registration process?

[shoneill]

QUOTE (Eugen Graf @ Jul 10 2008, 06:29 PM)

Yes! But UEs have some disadvantages:

I can't flush UEs

I can't preview UEs

I can't get status of UEs (need count of elements in my programms)

It's clear that there is some functionality which is NOT given with UEs. When I look at the code for registering / broadcasting and so on, I still think UEs are a good choice for any multicast type of functionality. Would it not be effectively less code to have a small unit (single VI to run in parallel to the main VI) on each recipient's side with an event case registering for the event in question and sticking them into a local queue to add the required functionality? So this would be like using the UE for distribution, but a local queue for storage.....

Disclaimer: I'vce often thought about something like this, but never actually implemented it. As such there may be some glaring disadvantage in my suggestion.

Shane.