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?
--
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
