diff options
| author | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2014-05-02 10:31:09 +0200 |
|---|---|---|
| committer | Sebastian Huber <sebastian.huber@embedded-brains.de> | 2014-05-07 14:26:28 +0200 |
| commit | 38b59a6d3052654e356ae16b4a243c362312acce (patch) | |
| tree | 9d19ed78a331839a2f292572ddbfa44091efd347 /cpukit/rtems | |
| parent | score: Delete _SMP_Test_message_default_handler (diff) | |
| download | rtems-38b59a6d3052654e356ae16b4a243c362312acce.tar.bz2 | |
score: Implement forced thread migration
The current implementation of task migration in RTEMS has some
implications with respect to the interrupt latency. It is crucial to
preserve the system invariant that a task can execute on at most one
processor in the system at a time. This is accomplished with a boolean
indicator in the task context. The processor architecture specific
low-level task context switch code will mark that a task context is no
longer executing and waits that the heir context stopped execution
before it restores the heir context and resumes execution of the heir
task. So there is one point in time in which a processor is without a
task. This is essential to avoid cyclic dependencies in case multiple
tasks migrate at once. Otherwise some supervising entity is necessary to
prevent life-locks. Such a global supervisor would lead to scalability
problems so this approach is not used. Currently the thread dispatch is
performed with interrupts disabled. So in case the heir task is
currently executing on another processor then this prolongs the time of
disabled interrupts since one processor has to wait for another
processor to make progress.
It is difficult to avoid this issue with the interrupt latency since
interrupts normally store the context of the interrupted task on its
stack. In case a task is marked as not executing we must not use its
task stack to store such an interrupt context. We cannot use the heir
stack before it stopped execution on another processor. So if we enable
interrupts during this transition we have to provide an alternative task
independent stack for this time frame. This issue needs further
investigation.
Diffstat (limited to 'cpukit/rtems')
| -rw-r--r-- | cpukit/rtems/include/rtems/rtems/tasks.h | 2 | ||||
| -rw-r--r-- | cpukit/rtems/src/tasksetscheduler.c | 5 |
2 files changed, 2 insertions, 5 deletions
diff --git a/cpukit/rtems/include/rtems/rtems/tasks.h b/cpukit/rtems/include/rtems/rtems/tasks.h index 43e8c8ac9d..a14e865ada 100644 --- a/cpukit/rtems/include/rtems/rtems/tasks.h +++ b/cpukit/rtems/include/rtems/rtems/tasks.h @@ -569,8 +569,6 @@ rtems_status_code rtems_task_get_scheduler( * * @retval RTEMS_SUCCESSFUL Successful operation. * @retval RTEMS_INVALID_ID Invalid task or scheduler identifier. - * @retval RTEMS_INCORRECT_STATE The task is in the wrong state to perform a - * scheduler change. * * @see rtems_scheduler_ident(). */ diff --git a/cpukit/rtems/src/tasksetscheduler.c b/cpukit/rtems/src/tasksetscheduler.c index 42c08bbb80..30c7c6b3e2 100644 --- a/cpukit/rtems/src/tasksetscheduler.c +++ b/cpukit/rtems/src/tasksetscheduler.c @@ -30,15 +30,14 @@ rtems_status_code rtems_task_set_scheduler( if ( _Scheduler_Get_by_id( scheduler_id, &scheduler ) ) { Thread_Control *the_thread; Objects_Locations location; - bool ok; the_thread = _Thread_Get( id, &location ); switch ( location ) { case OBJECTS_LOCAL: - ok = _Scheduler_Set( scheduler, the_thread ); + _Scheduler_Set( scheduler, the_thread ); _Objects_Put( &the_thread->Object ); - sc = ok ? RTEMS_SUCCESSFUL : RTEMS_INCORRECT_STATE; + sc = RTEMS_SUCCESSFUL; break; #if defined(RTEMS_MULTIPROCESSING) case OBJECTS_REMOTE: |