Experimental Physics and
Industrial Control System

rivers via Core-talk <core-talk at aps.anl.gov> · Thu, 26 Mar 2020 14:43:53 -0000

I have modified libcom/test/epicsMessageQueueTest.cpp to add 2 new
tests.  Both tests send 1000 messages to a new receiver thread.  The
receiver thread calls q->receive() with a 0.01 second timeout.  In the
first test there is an epicsThreadSleep of 0.011 seconds in the
q->send() loop.  In the second test the sleep is 0.010 seconds.

These are the important results:
# Single receiver with timeout, single sender with sleep tests:
# These tests last 20 seconds ...
ok 57 - sleep=0.011
not ok 58 - sleep=0.010
# numSent should be 1000, actual=1000, numReceived should be 1000, actual=935

** Attachment added: "Complete results from patched epicsMessageQueueTest.cpp"
   https://bugs.launchpad.net/epics-base/+bug/1868486/+attachment/5341841/+files/test_results.txt

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1868486

Title:
  epicsMessageQueue lost messages

Status in EPICS Base:
  Confirmed
Status in EPICS Base 3.15 series:
  New
Status in EPICS Base 7.0 series:
  Confirmed

Bug description:
  https://epics.anl.gov/core-talk/2020/msg00396.php

  Mark Rivers observed epicsMessageQueue losing messages.

  https://epics.anl.gov/core-talk/2020/msg00408.php

  > I think I see the logic error in how the eventSent flag is handled,
  > specifically related to the fact that epicsEvent is a semaphore as
  > opposed to a condition variable.
  > 
  > This allows a "race" to occur if the first/only waiting receiver
  > times out, and epicsEventWaitWithTimeout() returns, while a sender
  > is in epicsMessageQueueSend() preparing to wake up a receiver.
  > 
  > This results in a situation where the sender has set the eventSent,
  > and indeed copied a message to the buffer of, a thread which has
  > decided to abort.
  > 
  > After timing out, the receiver sees the timeout and returns -1
  > even through eventSent has been set.  This can be trapped with:
  > 
  > > b osdMessageQueue.cpp:358 if status!=0 && threadNode.eventSent
  > 
  > So here is your lost message.
  > 
  > Now when epicsMessageQueueReceiveWithTimeout() is called again, no message
  > is waiting in the queue, so epicsEventWaitWithTimeout() is called.
  > Since the semaphore is already set, this returns immediately with status==0,
  > but this is a spurious wakeup and the eventSent flag is not set.
  > 
  > And here is the second "timeout".

  Line numbers circa 7.0.3.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1868486/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System