Jump to content

multiple queue implementation.


Recommended Posts

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

Link to comment

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

Link to comment

QUOTE (Eugen Graf @ Jul 8 2008, 11:01 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

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.