On Tue, Mar 28, 2017 at 7:09 AM, Joe Savage <[email protected]> wrote: > On 28/03/17 12:13, Bill Fischofer wrote: >> On Tue, Mar 28, 2017 at 4:10 AM, Ola Liljedahl <[email protected]> >> wrote: >>> 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); >>>> } >> >> rc == 0 from odp_queue_enq() simply means that the enqueue request has >> been accepted. >> >> odp_queue_deq() removes the first element available on the specified queue. >> >> As Ola points out, depending on the implementation there may be some >> latency associated with queue operations so it is possible for the >> assert to fire. Of course, in a multi-threaded environment some other >> thread may have dequeued the event first as well, so this sort of code >> is inherently brittle. > > Ok, perfect, thanks guys. I'm glad that the operation is defined this way. > Somebody should probably update the validation tests to reflect this, though, > and it might be worth making the documentation a little more explicit about > it too.
Feel free to submit a documentation update patch :)
