Are Queues thread safe

[tadders]

Hi all,

Are Queues thread safe i.e. are enqueue, dequeue etc atomic?

I'm looking to use Queues to transfer object states between concurrent loops, but am concerned whether I need to protect access via a semaphore.

Thanks

Phill

[nathand · Accepted solution]

Yes.  Queue operations are atomic.  It's safe to assume everything in LabVIEW is thread safe unless specifically noted otherwise, since it has always been a language designed for parallel operation.

[Mark_Yedinak]

To the best of my knowledge they are thread safe.

[Ben]

All operation that are not thread-safe will run in the UI thread. To the best of my knowlege, this is mostly

property nodes

Open VI

VI Serve Call by reference (will not bet on this one)

dll calls if not set as thread-safe...

AND the Open Application Ref (according to the bug I just chased down that is crashing LV 2009 under Windows 7 )

Ben

[tadders]

Thanks very much for your input

Phill

[tadders]

Hi all,

I've been discussing transfering the state of an object between concurrent loops here and was hoping to use a single element queue.

I'm still a little worried about a context switch while I'm updating the status of the object in the area highlighted.

Would I still need a semaphore lock to ensure the data integrity of the queue between the flush and enqueue in case the data loop sneaks in and tries to read the queue?

[tst]

You're using the SEQ concept incorrectly. Do a search to see examples of how to use it properly, but basically, you CAN'T use Flush Queue or Preview. You have to use Dequeue because that includes the infinite timeout option, which is critical to the correct operation of a SEQ global.

Also, don't use events to pass the data around. If it's contained in your SEQ, keep it there and only there. If you want to make sure the loop has the current data, place the data in the queue before sending the event.

[tadders]

Thanks tst,

I think you mean something like this, where the data loop dequeues changes to the object state -

Is there anyway of using an asynchronous wake up for the timed loop to transfer state?

 

[tst]

I still don't understand which data you expect to share and where, which means I still don't know if the SEQ ref has to be part of the object, or whether you can stuff the entire object into the ref.

In any case, when you use a SEQ, you need to manage all the data using DeQ and EnQ, each DeQ must have a corresponding EnQ and DeQs should have an infinite timeout. Like I said, search for examples. 

If a loop only needs commands from an actual queue (not a SEQ), then you can simply use an infinite timeout for its DeQ. It will sleep until the queue has something.