Do Queues need semaphore protection for a Read Only op?

[TG]

Are Queues naturally safe for a Read only op? (as in using the "Preview Queue Element" op)

Is it generally safe to Read from a Queue anytime, even if it is in the process of being written to?

Does LabVIEW handle it naturally or do I have to?

Thank You,

JR

[Tomi Maila]

As far as I know there is no need for semaphores. Queues are thread safe.

[TG]

QUOTE(Tomi Maila @ Jul 5 2007, 08:10 PM)

As far as I know there is no need for semaphores. Queues are thread safe.

Thanks Tomi.

[Tomi Maila]

What kind of thread safety are you expecting actually? What is the use case where you need thread safe queue access?

I ask because there may be use cases that are not implementable without external semaphore mechanism. Consider for example that you want to have a queue that has always two elements and you want always to preview the second element. Still you want to be able to remove the elements and add new elements to the queue. Even though the queue is thread safe, you cannot guarantee that there always is two elements in the queue when you try to preview it. Therefore if you would like to guarantee that there always is exactly two elements in the queue when you preview it, you would need to have another semaphore mechanism. The best semaphore mechanism I know of is a (single sized) queue itself

Tomi

[TG]

I want to use a named queue with a size of one (1) that is "written to" from one place at a time but

is also monitored from 1+ places at a time without concern for timing.

Like a simulated memory location referred to by name.

To "Write" to this "Memory location" requires a quick "Dequeue" then an "Enqueue element at Opposite End" to update.

That means there is a chance that the queue could be empty for a very short time, however

would a simple timeout value on the reader side "Preview queue element" be capable to handle this blip in the read only access?

I need to avoid having "Preview queue element" returning corrupted data or no data at all.

[eaolson]

QUOTE(John Rouse @ Jul 5 2007, 08:47 PM)

I want to use a named queue with a size of one (1) that is "written to" from one place at a time but

is also monitored from 1+ places at a time without concern for timing.

It sounds like you might be able to use a notifier. With a 0 wired to the timeout, you will always get back the last value put into the notifier. You don't have to worry about the queue ever being empty.

[mgunning]

Once you have created your single element queue:

To write to the queue all you need to do is dequeue, and then enqueue the new element (no point to enqueue at the opposite end since the queue can only have one element).

To read from the queue, dequeue and then enqueue the same element.

Make sure the timeout on all the dequeues is set to -1. Then if the queue is empty (because something else has temporarily emptied it), the dequeue will wait until an element has been put back in the queue.

Of course, you have to make sure that the queue doesn't become permanently empty, since then all the dequeues will hang when trying to read an empty queue.

Mark.

[Tomi Maila]

When you preview a queue element and there is no data in the queue, then the preview operation waits data until timeout. If there is still no data when the timeout occurs, preview queue returns timeout. The value returned when timeout has occurred has not been specified.

Tomi

[LAVA 1.0 Content]

I would also consider using a Notifier. A Notifier is a single element lossy queue. Wait on Notification has an option to "ignore previous (F)".

If set to true, the Wait primitive will retrieve the current Notifier count on each invocation and then block until the notification count increases. If false, the Wait on Notifier primitive will use the counter from the previous invocation and block until the notification count increases.

The important thing to remember is that the notifier is lossy. If you send notifications faster than you receive/handle them you may miss some data.

http://forums.lavag.org/index.php?act=attach&type=post&id=6316

[David Wisti]

A single-process shared variable with a single element RT FIFO enabled will accomplish this without any code.

QUOTE(John Rouse @ Jul 5 2007, 09:47 PM)

I want to use a named queue with a size of one (1) that is "written to" from one place at a time but

is also monitored from 1+ places at a time without concern for timing.

Like a simulated memory location referred to by name.

To "Write" to this "Memory location" requires a quick "Dequeue" then an "Enqueue element at Opposite End" to update.

That means there is a chance that the queue could be empty for a very short time, however

would a simple timeout value on the reader side "Preview queue element" be capable to handle this blip in the read only access?

I need to avoid having "Preview queue element" returning corrupted data or no data at all.

[Tomi Maila]

QUOTE(LV Punk @ Jul 6 2007, 02:32 PM)

The important thing to remember is that the notifier is lossy.

Another important thing to remember with notifiers is that a single "wait for notification" (W4N) node should only be used with a single notifier reference only. As a result W4N nodes should not be used in subVIs that could be called from multiple different parts of any application. The problem with W4N nodes is that they ignore all notifiers send before the last notifier they received. Therefore if a single W4N node is used with multiple notifier references, for example when W4N node is in a subVI, the notifier being processed may be actually sent before the previous notifier handled. As a result the program may hang. So if you are looking for a thread safe way to do things, queues are definitely safer way to go. If you feel you are absolutely familiar with this counter-intuitive way W4N nodes work, then go ahead and use them. I've not used notifiers since I found this odd behaviour and I guess I never will.

Link to the thread that covers the inner secrets of how notifiers actually work

http://forums.lavag.org/Notifier-signals-missed-t4220.html''>http://forums.lavag.org/Notifier-signals-missed-t4220.html' target="_blank">http://forums.lavag.org/Notifier-signals-missed-t4220.html

Tomi

[Jim Kring]

QUOTE(Tomi Maila @ Jul 6 2007, 07:16 AM)

Another important thing to remember with notifiers is that a single "wait for notification" (W4N) node should only be used with a single notifier reference only. As a result W4N nodes should not be used in subVIs that could be called from multiple different parts of any application. The problem with W4N nodes is that they ignore all notifiers send before the last notifier they received.

I believe that you can safely put Wait for Notification inside a subVI, only if it is reentrant. This way, each subVI is a unique instance.

However, this might cause some issues with some of the new clone pooling features. Hmmm... more food for thought.

[Tomi Maila]

QUOTE(Jim Kring @ Jul 6 2007, 05:38 PM)

I believe that you can safely put Wait for Notification inside a subVI, only if it is reentrant. This way, each subVI is a unique instance.

If there is a call chain of a subVIs calling other subVIs and so on, the only safe way to use Wait for Notification is to have all the subVIs in the call chain to be reentrant.

[eaolson]

QUOTE(Tomi Maila @ Jul 6 2007, 09:16 AM)

So if you are looking for a thread safe way to do things, queues are definitely safer way to go.

Except that Aristos Queue has said that notifiers actually are queues, behind the scenes. Have you tried recreating your example with single element queues to see if it still gets stuck?

[Tomi Maila]

QUOTE(eaolson @ Jul 6 2007, 08:46 PM)

Except that Aristos Queue has said that notifiers actually are queues, behind the scenes. Have you tried recreating your example with single element queues to see if it still gets stuck?

Queues don't have the same issue. This issue is notifier related only.

[Jim Kring]

QUOTE(Tomi Maila @ Jul 6 2007, 11:32 AM)

Queues don't have the same issue. This issue is notifier related only.

This issue also affects Occurrences (Wait on Occurrence).

[TG]

Based on the responses (Thanks BTW) I take it a simple timeout value on the

"Preview queue element" would cover any potential issue

since 'Preview queue element" will wait for valid data before timing out with an error.

BTW I am using only one ref to this Queue. It is obtained once in the object's Create method and then stored as an attribute. I wasnt sure if this mattered so just playing it safe.

I am using a Named object and use the Name to create a unique queue inside the object. Again just playing it safe.

The whole idea is to have a memory location that is specific to the process (object) instance and only that instance. This way two or three process's can operate independently and each process can have a method for doing/updating and seperate (reentrant) methods for monitoring.

I understand the notifier but admittedly

the behavior of notifiers is something I seldom can think of a "use case" for in my programming.

Whats a really good use case for a Notifier (over a queue) anyway?

Thank You

JR

[Michael Aivaliotis]

QUOTE(John Rouse @ Jul 6 2007, 09:23 PM)

BTW I am using only one ref to this Queue. It is obtained once in the object's Create method and then stored as an attribute. I wasnt sure if this mattered so just playing it safe.

I am using a Named object and use the Name to create a unique queue inside the object. Again just playing it safe.

The main benefit of naming queues is if you are obtaining a queue by name somewhere. If not ,then this has no benefit. Queue references don't need names.

QUOTE(John Rouse @ Jul 6 2007, 09:23 PM)

The whole idea is to have a memory location that is specific to the process (object) instance and only that instance. This way two or three process's can operate independently and each process can have a method for doing/updating and seperate (reentrant) methods for monitoring.

I'm not sure I follow. What OO framework are you using? OpenGoop, LVOOP? If you create a new instance of your object then doesn't each instance already have a place to store data?

QUOTE(John Rouse @ Jul 6 2007, 09:23 PM)

I understand the notifier but admittedly

the behavior of notifiers is something I seldom can think of a "use case" for in my programming.

Whats a really good use case for a Notifier (over a queue) anyway?

Notifiers are basically occurrences with data. usually used to "wake up" loops and at the same time pass data to them. With the release of dynamic events and event structures, they become less important however still useful sometimes.

[TG]

QUOTE(Michael_Aivaliotis @ Jul 8 2007, 03:11 AM)

The main benefit of naming queues is if you are obtaining a queue by name somewhere. If not ,then this has no benefit. Queue references don't need names.

Good point. I was beginning to think the same thing.

Since it is already part of the named instance naming it

would not give any benefit.

QUOTE(Michael_Aivaliotis @ Jul 8 2007, 03:11 AM)

I'm not sure I follow. What OO framework are you using? OpenGoop, LVOOP? If you create a new instance of your object then doesn't each instance already have a place to store data?

I am using Endevo GOOP2 objects that represent actual hardware device types and specific (child) devices. It is true that each has a place to store data and I did think of just using attributes to store the current "status" as the object method continues doing its task (looping + measuring.)

But there is an application level need to monitor all "active" processes from one (1) and possibly (1+) locations (as in getting the latest measurement or process value with timestamp etc) I thought a queue would be a fair solution. With a queue I could create a so called "data window" that would make "progress" of the method "visible" with as little overhead as possible (once the queueREF is obtained via another public method.)

My assumption is that writing to a queue is faster then locking, writing then unlocking an attribute many times in a loop. (not tested this mind you)

I'd be interested to know if this is not correct.

QUOTE(Michael_Aivaliotis @ Jul 8 2007, 03:11 AM)

Notifiers are basically occurrences with data. usually used to "wake up" loops and at the same time pass data to them. With the release of dynamic events and event structures, they become less important however still useful sometimes.

Thats true I had forgotten that anywhere an occurence is used a notifier will work too, only with better control since it can be

reused, destroyed etc...

Thank You

JR

[Neville D]

QUOTE(dwisti @ Jul 6 2007, 06:11 AM)

A single-process shared variable with a single element RT FIFO enabled will accomplish this without any code.

True, but a single element Q will be computationally more efficient with less overhead thanthe shared variable architecture.

Neville.

[Michael Aivaliotis]

QUOTE(John Rouse @ Jul 7 2007, 11:10 PM)

My assumption is that writing to a queue is faster then locking, writing then unlocking an attribute many times in a loop. (not tested this mind you)

I'd be interested to know if this is not correct.

This is correct. Locking, writing then unlocking in a loop is bad and should be avoided unless the core of the OOP framework is optimized. For example, using the http://wiki.openg.org/OpenG_Class_Templates_for_LabVIEW_Object-Oriented_Programming' target="_blank">OpenG Template for queue based by-reference classes.