[PATCH 4/6] spintrcritical20: Fix incorrect assumption

[Joel Sherrill]

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.

On Jul 9, 2014 9:32 AM, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
On 2014-07-08 22:52, Joel Sherrill wrote:
> The test assumed that the thread would have enough time to block
> and become enqueued. In fact, the thread would still be in the
> ready state and not blocked on the semaphore. Thus the state
> of the Wait sub-structure in the TCB would not be in the expected
> state. The simple solution was to continue when the thread was
> in the ready state.
> ---
>   testsuites/sptests/spintrcritical20/init.c |    4 ++++
>   1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/testsuites/sptests/spintrcritical20/init.c b/testsuites/sptests/spintrcritical20/init.c
> index cae8fdb..209c9e5 100644
> --- a/testsuites/sptests/spintrcritical20/init.c
> +++ b/testsuites/sptests/spintrcritical20/init.c
> @@ -20,6 +20,7 @@
>   #include <intrcritical.h>
>   #include <rtems/score/threadqimpl.h>
>   #include <rtems/rtems/semimpl.h>
> +#include <rtems/score/statesimpl.h>
>
>   const char rtems_test_name[] = "SPINTRCRITICAL 20";
>
> @@ -108,6 +109,9 @@ static void Init(rtems_task_argument ignored)
>         ++resets;
>       }
>
> +    if (ctx->semaphore_task_tcb->current_state == STATES_READY)
> +      continue;

In case the semaphore task is ready at this point, then we have a massive
problem since the semaphore task has a higher priority.

> +
>       _Thread_Disable_dispatch();

Should this check move to here?

>
>       rtems_test_assert(
>


--
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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140709/edd48a2b/attachment-0002.html>