<p dir="ltr"><br>
On Jul 10, 2014 2:14 AM, Sebastian Huber <sebastian.huber@embedded-brains.de> wrote:<br>
><br>
> On 2014-07-09 16:37, Joel Sherrill wrote:<br>
> > I think this patch is wrong. Subsequent changes to the thread queue after I<br>
> > posted this resulted in the test breaking again.<br>
> ><br>
> > What is the test trying to do? I think sometimes through the loop, the<br>
> > condition the test expects is not occurring and it fails.<br>
> ><br>
><br>
>  From the doc file we have:<br>
><br>
>    - Ensure that _Thread_queue_Process_timeout() works in case it is<br>
>      interrupted and _Thread_queue_Dequeue() is called.<br>
><br>
> It simulates a nested interrupt case.  Since we can use only the clock tick to <br>
> work with interrupts I had to do the following:<br>
><br>
> 1. Create a high priority task which creates the base state (semaphore locked).<br>
><br>
> 2. Use a low priority task to simulate the timeout process.<br>
><br>
> 3. Use a timer to simulate the high priority nested interrupt.<br>
><br>
> I think this is the only test which uses this approach so far.  This partly <br>
> explains why bugs like this prevailed for such a long time:<br>
><br>
> https://www.rtems.org/bugzilla/show_bug.cgi?id=2140<br>
><br>
> Do you not hit the test case or do you hit an assertion failure?</p>
<p dir="ltr">I hit the assertion case and suspect that it happens when the blocking thread has not gotten far enough along to be in a state where process timeout even sees it. I will debug more. </p>
<p dir="ltr">I don't think it is very broken. Just asserting conditions that are true most but not all of the time.</p>
<p dir="ltr">> -- <br>
> Sebastian Huber, embedded brains GmbH<br>
><br>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> Phone   : +49 89 189 47 41-16<br>
> Fax     : +49 89 189 47 41-09<br>
> E-Mail  : sebastian.huber@embedded-brains.de<br>
> PGP     : Public key available on request.<br>
><br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</p>