Enqueue in multithreaded environment

[pwaszkewitz]

Hello,

is the Enqueue step self-synchronizing, i.e. is it ensured, if two threads try to enqueue into the same queue at (practically) the same time, that both enqueues succeed (eventually, i.e., after some waiting time for one of the threads)?

If so, then one of the steps will certainly have to wait for the other to finish. Is it possible to give an estimate of the required time-out?

Background: the step is currently configured with a 200 time-out. Our trace files have logged wo enqueue trials by different threads with a time difference of approx. 200ms. One of the enqueued data structures was never dequeued and the queue did not contain any residual elements. So I assume that one of the two enqueues failed and that it may have run into its timeout. This would explain the trace entries as well as the missing dequeue.

Regards

Peter

[dug9000]

---

@pwaszkewitz wrote:

Hello,

is the Enqueue step self-synchronizing, i.e. is it ensured, if two threads try to enqueue into the same queue at (practically) the same time, that both enqueues succeed (eventually, i.e., after some waiting time for one of the threads)?

If so, then one of the steps will certainly have to wait for the other to finish. Is it possible to give an estimate of the required time-out?

Background: the step is currently configured with a 200 time-out. Our trace files have logged wo enqueue trials by different threads with a time difference of approx. 200ms. One of the enqueued data structures was never dequeued and the queue did not contain any residual elements. So I assume that one of the two enqueues failed and that it may have run into its timeout. This would explain the trace entries as well as the missing dequeue.

Regards

Peter

---

Yes, the TestStand synchronization step types are intended to be used from a multi-threaded environment where multiple threads might be accessing them in parallel.

The time out setting for enqueuing only takes affect when the queue is full. It has nothing to do with two enqueues happening at about the same time, rather it is for when the queue is full and the enqueue must then wait for another thread to dequeue something or clear the queue. If the queue is not full then the time out does not apply. If however the queue was full and you have configured the step to time out and you have unchecked the checkbox where the time out is set to cause a run-time error, then yes, the step is configured to silently fail to enqueue things when the queue is full and the time out occurs. If you do not want this behavior then you should either disable the time out, or set the time out to cause a run-time error (so the problem won't happen silently and you will be notified about it). The reason why the setting for time outs causing runtime errors is checked by default is because silently failing to enqueue things is generally not what people want, the option does exist though in case someone has a situation where not enqueuing something on time out is what they want.

Hope this helps explain things,

-Doug