RTEMS 6.3
Loading...
Searching...
No Matches

Tests SMP-specific thread behaviour. More...

Files

file  testsuites/validation/tc-score-smp-thread.c

Data Structures

struct  ScoreThreadValSmp_Context
 Test context for spec:/score/thread/val/smp test case. More...

Macros

#define EVENT_A_OBTAIN   RTEMS_EVENT_0
#define EVENT_A_RELEASE   RTEMS_EVENT_1
#define EVENT_B_OBTAIN   RTEMS_EVENT_2
#define EVENT_B_RELEASE   RTEMS_EVENT_3
#define EVENT_COUNT_EARLY   RTEMS_EVENT_4
#define EVENT_BUSY   RTEMS_EVENT_5
#define EVENT_COUNT   RTEMS_EVENT_6
#define EVENT_LET_WORKER_C_COUNT   RTEMS_EVENT_7
#define EVENT_SET_TASK_SWITCH_EXTENSION   RTEMS_EVENT_8

Typedefs

typedef ScoreThreadValSmp_Context Context

Functions

Thread_queue_Deadlock_status __wrap__Thread_queue_Path_acquire (Thread_queue_Queue *queue, Thread_Control *the_thread, Thread_queue_Context *queue_context)
Thread_queue_Deadlock_status __real__Thread_queue_Path_acquire (Thread_queue_Queue *queue, Thread_Control *the_thread, Thread_queue_Context *queue_context)
 T_TEST_CASE_FIXTURE (ScoreThreadValSmp, &ScoreThreadValSmp_Fixture)

Detailed Description

Tests SMP-specific thread behaviour.

This test case performs the following actions:

  • Create three worker threads and a mutex. Use the mutex and the worker to move to a helping scheduler.
    • Pin the runner thread while it executes on a processor owned by a helping scheduler.
    • Pin and unpin the runner thread. This is a nested operation.
    • Preempt the pinned runner thread. Worker B and C execute at the same time on processor 0 and 1 respectively for some point in time. This shows that the pinning of the runner thread is maintained.
    • Unpin the runner thread. The runner moves back to its home scheduler.
    • Release the mutex.
    • Pin the runner thread. Unpin the runner thread while it is suspended.
    • Make sure the worker released the mutex.
    • Clean up all used resources.
  • Create three worker threads and a mutex. Use the mutex and the worker to check that a suspended thread does not reconsider help requests.
    • Let worker B help worker A through the mutex. Preempt worker A. Delay the thread switch to worker A.
    • Suspend worker A and let it wait on its thread state lock. Check that worker A did not reconsider help requests.
    • Resume worker A. Check that worker A did reconsider help requests after the thread dispatch.
    • Clean up all used resources.
  • Create four worker threads and three mutexes. Provoke an explicit thread priority change while a priority inheritance change is in progress. The explicit thread priority change propagates through priority inheritance.
    • Create the following dependencies MA -> WA and TC -> MB -> WA.
    • Acquire the worker A default thread wait lock. Start creating the dependency TB -> MB (we already have MB -> WA). Make sure it stops while acquiring the worker A default thread wait lock. Prepare the worker A default thread wait lock release. Raise the worker C priority. This operation will call the wrapped _Thread_queue_Path_acquire() and trigger the prepared release of the worker A default thread wait lock. The worker A default wait lock critical sections will execute now in the prepared sequence.
    • Clean up all used resources.