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