source: rtems/cpukit/score/src/schedulerpriorityunblock.c @ 9bfad8c

5
Last change on this file since 9bfad8c was 9bfad8c, checked in by Sebastian Huber <sebastian.huber@…>, on 06/08/16 at 20:22:46

score: Add thread priority to scheduler nodes

The thread priority is manifest in two independent areas. One area is
the user visible thread priority along with a potential thread queue.
The other is the scheduler. Currently, a thread priority update via
_Thread_Change_priority() first updates the user visble thread priority
and the thread queue, then the scheduler is notified if necessary. The
priority is passed to the scheduler via a local variable. A generation
counter ensures that the scheduler discards out-of-date priorities.

This use of a local variable ties the update in these two areas close
together. For later enhancements and the OMIP locking protocol
implementation we need more flexibility. Add a thread priority
information block to Scheduler_Node and synchronize priority value
updates via a sequence lock on SMP configurations.

Update #2556.

  • Property mode set to 100644
File size: 1.9 KB
Line 
1/**
2 *  @file
3 *
4 *  @brief Scheduler Priority Unblock
5 *  @ingroup ScoreScheduler
6 */
7
8/*
9 *  Scheduler Handler
10 *
11 *  Copyright (C) 2010 Gedare Bloom.
12 *  Copyright (C) 2011 On-Line Applications Research Corporation (OAR).
13 *
14 *  The license and distribution terms for this file may be
15 *  found in the file LICENSE in this distribution or at
16 *  http://www.rtems.org/license/LICENSE.
17 */
18
19#if HAVE_CONFIG_H
20#include "config.h"
21#endif
22
23#include <rtems/score/schedulerpriorityimpl.h>
24
25Scheduler_Void_or_thread _Scheduler_priority_Unblock (
26  const Scheduler_Control *scheduler,
27  Thread_Control          *the_thread
28)
29{
30  Scheduler_priority_Context *context;
31  Scheduler_priority_Node    *node;
32  unsigned int                priority;
33  bool                        prepend_it;
34
35  context = _Scheduler_priority_Get_context( scheduler );
36  node = _Scheduler_priority_Thread_get_node( the_thread );
37  priority = _Scheduler_Node_get_priority( &node->Base, &prepend_it );
38  (void) prepend_it;
39
40  if ( priority != node->Ready_queue.current_priority ) {
41    _Scheduler_priority_Ready_queue_update(
42      &node->Ready_queue,
43      priority,
44      &context->Bit_map,
45      &context->Ready[ 0 ]
46    );
47  }
48
49  _Scheduler_priority_Ready_queue_enqueue(
50    &the_thread->Object.Node,
51    &node->Ready_queue,
52    &context->Bit_map
53  );
54
55  /* TODO: flash critical section? */
56
57  /*
58   *  If the thread that was unblocked is more important than the heir,
59   *  then we have a new heir.  This may or may not result in a
60   *  context switch.
61   *
62   *  Normal case:
63   *    If the current thread is preemptible, then we need to do
64   *    a context switch.
65   *  Pseudo-ISR case:
66   *    Even if the thread isn't preemptible, if the new heir is
67   *    a pseudo-ISR system task, we need to do a context switch.
68   */
69  if ( priority < _Thread_Heir->current_priority ) {
70    _Scheduler_Update_heir( the_thread, priority == PRIORITY_PSEUDO_ISR );
71  }
72
73  SCHEDULER_RETURN_VOID_OR_NULL;
74}
Note: See TracBrowser for help on using the repository browser.