On 28 March 2017 at 10:41, Joe Savage <[email protected]> wrote: > Hey, > > I just wanted to clarify something about the expected behaviour of > odp_queue_enq. In the following code snippet, is it acceptable for the assert > to fire? (i.e. for a dequeue after a successful enqueue to fail, with only a > single thread of execution) > > odp_queue_t queue; > odp_event_t ev1, ev2; > /* ... */ > if (odp_queue_enq(queue, ev1) == 0) { > ev2 = odp_queue_deq(queue); > assert(ev2 != ODP_EVENT_INVALID); > } > > That is, can the "success" status code from odp_queue_enq be used to indicate > a delayed enqueue ("This event will be added to the queue at some point > soon-ish"), or should it only be used to communicate an immediate successful > addition to the queue? The documentation seems unclear on this point while > the validation tests suggest the latter, but I thought it worth checking up > on. Some code in odp_scheduling test/benchmark also expects an enqueued event to be immediately dequeuable by the same thread.
I think this is not something you can require, neither from a HW queue manager or from a SW implementation. HW implementations can always have associated latencies visible to the thread that enqueues/dequeues. Also for a SW implementation with loosely coupled parts (e.g. producer & consumer head & tail pointers) it can be possible for an enqueued event to not be immediately available when other threads are doing concurrent operations on the same queue. Only if a lock protects the whole data structure can you enforce one global view of this data structure. You don't want to use a lock. > > Thanks, > > Joe
