INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT

[Chris Johns]

On 21/02/2018 01:23, Sebastian Huber wrote:
> ----- Am 19. Feb 2018 um 12:41 schrieb Matthew J Fletcher amimjf at gmail.com:
> 
>> Hi,
>>
>> I've seen this in our application in certain use cases, if my understanding
>> is correct (an it might not be), it comes
>> from RTEMS_SCORE_ROBUST_THREAD_DISPATCH,
>> via CPU_ENABLE_ROBUST_THREAD_DISPATCH.
>>
>> It only seems to be TRUE for Arm, which seems a bit inconstant. However i
>> dont really understand what its trying to achieve, i see
>> https://devel.rtems.org/ticket/2954 but it does more than just optimise the
>> context switch, it significantly alters how an application should be
>> written, no more freeing memory with interrupts disabled etc,
> 
> Originally, the CPU_ENABLE_ROBUST_THREAD_DISPATCH was implemented for the SMP support (inter-processor interrupt delivery MUST be possible during operating system services). On ARMv7-M it catches an undefined behaviour case. On the other ARM variants it simplified the context switch code. In general, we could enable the CPU_ENABLE_ROBUST_THREAD_DISPATCH on all architectures. This would probably break some broken applications. 

This is a bit messy because it is clearly wrong on SMP while the Classic API's
`rtems_task_create` [1] lets a user set the mask level which is almost saying
"run a task at a specific mask level". I am not aware of an API call that lets a
user change this level and an interrupt disable and restore returns the task's
initial level so at some point being able to block with a specific mask level
was a requirement. Also on modern processors levels are handled in interrupt
controllers and not in the CPU so how much use is an initial mask level these days?

I am personally OK with a change to catch interrupts being masked in a context
switch because it is more likely this happens in error than on purpose and
catching this type of error without an internal check like this is hard. The
flow on of this is making obsolete setting the level on a task create.

I suspect setting the interrupt level on a task on an ARMv-7 would result in the
internal error if the user did not clear the interrupt mask before calling a
blocking call. This complicates the documentation because of per arch differences.

Also, the documentation should be updated noting the SMP exceptions. I have
raised #3309 to track this.

> You should never call an operating system service with interrupts disabled in thread context. This would destroy all the work done in the RTEMS implementation to keep the interrupt latency small.

I agree and so I question if we should allow a task's initial mask level to be
set this way?

My rational is making the API consistent on non-SMP and SMP targets and helping
to isolate a difficult case to catch.

Chris

[1]
https://docs.rtems.org/branches/master/c-user/task_manager.html#task-create-create-a-task