We have a unified work area. So depending on the memory layout the
task_id_p = malloc( sizeof( rtems_id ) );
rtems_test_assert( task_id_p );
or the
sc = rtems_task_create(
rtems_build_name('T','A',created_task_count, ' '),
1,
RTEMS_MINIMUM_STACK_SIZE,
RTEMS_DEFAULT_MODES,
RTEMS_DEFAULT_ATTRIBUTES,
task_id_p
);
rtems_test_assert(
(sc == RTEMS_UNSATISFIED) ||
(sc == RTEMS_TOO_MANY) ||
(sc == RTEMS_SUCCESSFUL)
);
may fail. If we are unlucky then we hit the first case and the test
fails.
Add a local context structure to the SMP lock API for acquire and
release pairs. This context can be used to store the ISR level and
profiling information. It may be later used to enable more
sophisticated lock algorithms, e.g. MCS locks.
There is only one lock that cannot be used with a local context. This
is the per-CPU lock since here we would have to transfer the local
context through a context switch which is very complicated.
This partially reverts commit 1215fd4d94.
In order to support profiling of SMP locks and provide a future
compatible SMP locks API it is necessary to add an SMP lock destroy
function. Since the commit above adds an SMP lock to each chain control
we would have to add a rtems_chain_destroy() function as well. This
complicates the chain usage dramatically. Thus revert the patch above.
A global SMP lock for all chains is used to implement the protected
chain operations.
Advantages:
* The SAPI chain API is now identical on SMP and non-SMP
configurations.
* The size of the chain control is reduced and is then equal to the
Score chains.
* The protected chain operations work correctly on SMP.
Disadvantage:
* Applications using many different chains and the protected operations
may notice lock contention.
The chain control size drop is a huge benefit (SAPI chain controls are
66% larger than the Score chain controls). The only disadvantage is not
really a problem since these applications can use specific interrupt
locks and unprotected chain operations to avoid this issue.
According to AAPCS, section 5.2.1.2, "Stack constraints at a public
interface" the stack must be 8 byte aligned. This was not the case
during interrupt processing.
Formerly POSIX keys were only enabled when POSIX threads
were enabled. Because they are a truly safe alternative
to per-task variables in an SMP system, they are being
enabled in all configurations.
This method exercises the ability to dynamically get and set
the affinity of POSIX threads.
NOTE: There is no scheduler support for affinity. This is
simply a data integrity test.
SMP must be initialized in order to know the current set of
cores available. Without this, you cannot initialize the
default cpu_set_t associated with Classic API tasks and
POSIX threads.
This new Score Handler provides a structure to manage a
cpu_set_t plus helper routines to validate the contents
against the current system configuration.
A new option RTEMS_INTERRUPT_REPLACE is introduced that permits updating
the first interrupt handler for the registered interrupt vector and
matching argument. If no match is found, the install function fails
with RTEMS_UNSATISFIED.
The Interrupt Manager Extension offers interrupt handlers with an
argument pointer. It is impossible to update two words (handler and
argument) atomically on most architectures. In order to avoid an SMP
lock in bsp_interrupt_handler_dispatch() which would degrade the
interrupt response time an alternative must be provided that makes it
possible to tear-down interrupt sources without an SMP lock.
Add RTEMS_INTERRUPT_REPLACE option to Interrupt Manager Extension. This
enables a clean tear-down of interrupt sources on SMP configurations.
Instead of an interrupt handler removal a replacement handler can be
installed to silence an interrupt source. This can be used in contexts
that allow no sophisticated synchronization (e.g. in atexit() or fatal
handlers).
