forked from Imagelibrary/rtems
fcb11510c6
In uniprocessor and SMP configurations, the context switch extensions
were called during _Thread_Do_dispatch():
void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
Thread_Control *executing;
executing = cpu_self->executing;
...
do {
Thread_Control *heir;
heir = _Thread_Get_heir_and_make_it_executing( cpu_self );
...
_User_extensions_Thread_switch( executing, heir );
...
_Context_Switch( &executing->Registers, &heir->Registers );
...
} while ( cpu_self->dispatch_necessary );
...
}
In uniprocessor configurations, this is fine and the context switch
extensions are called for all thread switches except the very first
thread switch to the initialization thread. However, in SMP
configurations, the context switch may be invalidated and updated in the
low-level _Context_Switch() routine. See:
https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-dispatch-details
In case such an update happens, a thread will execute on the processor
which was not seen in the previous call of the context switch
extensions. This can confuse for example event record consumers which
use events generated by a context switch extension.
Fixing this is not straight forward. The context switch extensions call
must move after the low-level context switch. The problem here is that
we may end up in _Thread_Handler(). Adding the context switch
extensions call to _Thread_Handler() covers now also the thread switch
to the initialization thread. We also have to save the last executing
thread (ancestor) of the processor. Registers or the stack cannot be
used for this purpose. We have to add it to the per-processor
information. Existing extensions may be affected, since now context
switch extensions use the stack of the heir thread. The stack checker
is affected by this.
Calling the thread switch extensions in the low-level context switch is
difficult since at this point an intermediate stack is used which is
only large enough to enable servicing of interrupts.
Update #3885.
This is the directory under which the RTEMS
test programs provided with the release are located. The
following is a description of the contents of each file and
subdirectory directly in this directory:
NOTE: Other than the 'samples' directory these tests are intended
only to exercise RTEMS features and are *not* good examples
of programming for RTEMS.
samples
This directory contains a set of simple sample applications
which can be used either to test a board support package
or as the starting point for a custom application.
mptests
This directory contains the RTEMS Multiprocessor Test Suite.
The tests in this directory provide near complete (98%+) test
coverage of the multiprocessor specific code in RTEMS.
psxtests
This directory contains the RTEMS POSIX API Test Suite.
The tests in this directory test the POSIX API support in RTEMS.
sptests
This directory contains the RTEMS Single Processor Test Suite.
The tests in this directory provide near complete (98%+) test
coverage of the non-multiprocessor code in RTEMS.
tmtests
This directory contains the RTEMS Timing Test Suite.
The tests in this directory are used to measure the execution
time of RTEMS directive and some critical internal functions.
The results of these test are reported in the Fact Sheets
and Supplental Manuals.