LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

CmtInstallTSQCallback

The documentation for CmtInstallTSQCallback notes that only one callback can be assigned for any particular event. Is this one callback for the entire application, or per thread? I have a situation where I have one writer and N readers, and would like all the readers to receive a callback when data is available in the queue.

In case you are wondering why, in my application I have a main tread, and then several other threads which each handle receiving data from a specific hardware device (via rs232, ethernet, or gpib). When the main thread has a command to send to one of the devices (issued via the GUI, or sent to it from another program over the network), it pushes the command into a thread-safe queue. The device threads each check the queue when they are not busy receiving data, and if the command is for their device, they execute it and then remove it from the queue. The reason that I am using a single queue for all the devices is to make it easy to ensure that commands are executed in the order that they are generated. I would like for reading to be handled by callbacks rather than polling in an attempt to decrease latency and processor usage, but wanted to check that this is possible before reworking the code.

0 Kudos
Message 1 of 2
(2,838 Views)
Hi,

The TSQ callback you register is called only in the (single) thread specified by the Callback Thread ID parameter.  One other option is to have a single dedicated "event dispatch" thread whose job it is to propogate TSQ events to all the other threads.  You would register this thread to process the TSQ events, and in the callback, it would call PostDeferredCallToThread (a UI library function) to schedule a check-if-the-message-was-for-me callback in each of the other threads.

This approach could potentially introduce some additional delay between when the TSQ first gets a new item and when the other threads actually start checking the queue because the event dispatch thread first has to get a chance to run, but in practice, it should be negligible.  Another requirement is that the event dispatch thread has access to the thread IDs of all the other threads.  You can probably just get away with having a simple global thread ID array and count without any thread protection, as long as the hardware IO threads are being destroyed/created carefully, one at a time.

Hope this helps.

Mert A.
National Instruments
Message 2 of 2
(2,831 Views)