rtems_message_queue_receive / rtems_event_receive issues

[Sebastian Huber]

On 12/10/2018 10:40, Catalin Demergian wrote:
> Hi,
> I still think it would be worth to try the latest RTEMS master just to
> make sure we don't search a bug which is already fixed. Also RTEMS 5 has
> more assertions in the debug configuration.
> -> is RTEMS 5 stable branch or development ?

It is the development branch of RTEMS. Most of the time it is stable.

> -> what is the link for RTEMS master (where to do a git clone from)  ?

git://git.rtems.org/rtems.git

>
> I have a theory of what may be going on, please let me know if you 
> think it's valid.
> 1. let's say Wait.flags = THREAD_WAIT_CLASS_EVENT 
> | THREAD_WAIT_STATE_INTEND_TO_BLOCK
>     and state = STATES_WAITING_FOR_EVENT because they are set this way 
> in _Event_Seize
> 2. USB ISR arrives, so we go in _Event_Surrender where
>     success = _Thread_Wait_flags_try_change_critical(
>       the_thread,
>       wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK,
>       ready_again
>     );
>     will return TRUE, because the expected flags was intend to block, 
> so Wait.flags will become THREAD_WAIT_CLASS_EVENT 
> | THREAD_WAIT_STATE_READY_AGAIN
> 3. _Event_Seize continues execution with
>       success = _Thread_Wait_flags_try_change(
>         executing,
>         intend_to_block,
>         wait_class | THREAD_WAIT_STATE_BLOCKED
>       );
>       and success will be FALSE because Wait.flags is not 
> THREAD_WAIT_STATE_INTEND_TO_BLOCK anymore, so _Thread_Unblock will get 
> called
>       and eventually _States_Clear will put state = STATES_READY.

Yes, and the _Thread_Unblock() will result in a call to 
_Scheduler_Unblock(). This adds the thread to the set of ready threads 
and it will execute as soon it is the highest priority ready thread.

> 4.  _Thread_Dispatch_enable will be called in _Event_Seize, but 
> another task is selected to run (I have 4 tasks with the same 
> priority, my task doesn't have a smaller
>      priority, it's not necessarily made the heir task)
> 5.  Another USB ISR arrives; this time we enter _Event_Surrender with
>      state = STATES_READY and Wait.flags = THREAD_WAIT_CLASS_EVENT 
> | THREAD_WAIT_STATE_READY_AGAIN,
>      so we go on the else branch, setting unblock = FALSE, not 
> calling _Thread_Unblock from _Event_Surrender.
> 6.  basically no matter how many USB ISRs will arrive, the same 
> scenario from step 5 repeats ... no one will call _Thread_Unblock for 
> SCrx again !
>      Also, when entering task command in the shell it shows the task 
> as ready (because it is) and the USB event set.

Once the thread is in the set of ready threads managed by the scheduler 
another call to _Thread_Unblock() is unnecessary.

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