EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: RTEMS/osdMessageQueue.c
From: Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>
To: "Johnson, Andrew N." <anj at anl.gov>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Date: Mon, 25 May 2020 11:37:01 -0700
A couple of things.

It looks like the switch to ci-scripts for Base added TEST=NO for the RTEMS builds.
This needs to be removed.

On 5/25/20 10:49 AM, Johnson, Andrew N. via Core-talk wrote:
> tl;dr:  I propose that we delete the RTEMS implementation of osdMessageQueue before making the 7.0.3.2 release, it has bugs which the default implementation doesn’t show.

I don't have a strong objection to this.  Although, I'm not enthused to be
making this change days before a release, when it will go out the door with
very little testing.  Whatever is going on, I suspect that it isn't a
regression (the bugs in the default impl weren't).

How about marking your new test as a skip until after the release?


> The long version:
> 
> While merging 3.15 into 7.0 last night I ran the tests on RTEMS (qemu) and discovered that the implementation of the epicsMessageQueue fails the additional tests that I wrote for this API. I was expecting the Travis-CI builds to fail but

> I forgot that they don’t actually run the tests at all.

I guess there is something to be said for developing on the development branch.


> In the RTEMS implementation of the epicsMessageQueue Eric added an rtems_message_queue_send_timeout() routine which the rtems_message_queue type doesn’t come with. These were the results I saw for these tests:
> 
>> # 6 Single receiver single sender 'Sleepy timeout' tests,
>> #     these should take about 5.00 seconds each:
>> # sleepySender: sending every 0.009 seconds
>> ok 57 - Sent 500 (should be 500)
>> ok 58 - Received 500 (should be 500)
>> # sleepySender: sending every 0.010 seconds
>> ok 59 - Sent 500 (should be 500)
>> ok 60 - Received 500 (should be 500)
>> # sleepySender: sending every 0.011 seconds
>> ok 61 - Sent 500 (should be 500)
>> ok 62 - Received 500 (should be 500)
>> # sleepyReceiver: acquiring every 0.009 seconds
>> not ok 63 - Sent 420 (should be 500)
>> ok 64 - Received 500 (should be 500)
>> # sleepyReceiver: acquiring every 0.010 seconds
>> not ok 65 - Sent 420 (should be 500)
>> ok 66 - Received 500 (should be 500)
>> # sleepyReceiver: acquiring every 0.011 seconds
>> not ok 67 - Sent 420 (should be 500)
>> ok 68 - Received 500 (should be 500)
> 
> So far every time I have run this test the numSent counter has always come back as 420 instead of 500. The fastSender() code looks like this:
> 
>> extern"C"void
>> fastSender(void*arg)
>> {
>>     epicsMessageQueue *q = (epicsMessageQueue *)arg;
>>     numSent= 0;
>>
>>     // Send first without timeout
>>     q->send((void*)msg1, 4);
>>     numSent++;
>>
>>     // The rest have a timeout
>>     while(!sendExit) {
>>         if(q->send((void*)msg1, 4, 0.010) == 0) {
>>             numSent++;
>>         }
>>     }
>>     sendExit = 0;
>>     epicsEventSignal(complete);
>> }
> 
> The epicsMessageQueueSendWithTimeout() routine must sometimes be returning an error (non-zero value) even though it has successfully queued the message; I confirmed that by incrementing a local numFailed counter on the else branch, which always counted to 580. This was the output from a normal run on linux, which is about what I would expect:
> 
>> # sleepyReceiver: acquiring every 0.009 seconds
>> ok 63 - Sent 500 (should be 500)
>> ok 64 - Received 500 (should be 500)
>> # numFailed = 0
>> # sleepyReceiver: acquiring every 0.010 seconds
>> ok 65 - Sent 500 (should be 500)
>> ok 66 - Received 500 (should be 500)
>> # numFailed = 204
>> # sleepyReceiver: acquiring every 0.011 seconds
>> ok 67 - Sent 500 (should be 500)
>> ok 68 - Received 500 (should be 500)
>> # numFailed = 500
> 
> Instead of trying to fix the RTEMS code I propose that we delete the RTEMS implementation completely, causing RTEMS to use the default implementation which gives me these test results when run on qemu:
> 
>> # 6 Single receiver single sender 'Sleepy timeout' tests,
>> #     these should take about 5.00 seconds each:
>> # sleepySender: sending every 0.009 seconds
>> ok 57 - Sent 500 (should be 500)
>> ok 58 - Received 500 (should be 500)
>> # sleepySender: sending every 0.010 seconds
>> ok 59 - Sent 500 (should be 500)
>> ok 60 - Received 500 (should be 500)
>> # sleepySender: sending every 0.011 seconds
>> ok 61 - Sent 500 (should be 500)
>> ok 62 - Received 500 (should be 500)
>> # sleepyReceiver: acquiring every 0.009 seconds
>> ok 63 - Sent 500 (should be 500)
>> ok 64 - Received 500 (should be 500)
>> # numFailed = 80
>> # sleepyReceiver: acquiring every 0.010 seconds
>> ok 65 - Sent 500 (should be 500)
>> ok 66 - Received 500 (should be 500)
>> # numFailed = 80
>> # sleepyReceiver: acquiring every 0.011 seconds
>> ok 67 - Sent 500 (should be 500)
>> ok 68 - Received 500 (should be 500)
>> # numFailed = 80
> 
> Any objections? Discussion?
> 
> - Andrew
> 
> -- 
> Complexity comes for free, simplicity you have to work for.
> 


Replies:
Re: RTEMS/osdMessageQueue.c Heinz Junkes via Core-talk
Re: RTEMS/osdMessageQueue.c Michael Davidsaver via Core-talk
Re: RTEMS/osdMessageQueue.c Johnson, Andrew N. via Core-talk
Re: RTEMS/osdMessageQueue.c Michael Davidsaver via Core-talk
References:
RTEMS/osdMessageQueue.c Johnson, Andrew N. via Core-talk

Navigate by Date:
Prev: Build failed: EPICS Base 7 base-7.0-15 AppVeyor via Core-talk
Next: Re: RTEMS/osdMessageQueue.c Heinz Junkes via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: RTEMS/osdMessageQueue.c Johnson, Andrew N. via Core-talk
Next: Re: RTEMS/osdMessageQueue.c Heinz Junkes via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 02 Jun 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·