1 | Symmetric Multiprocessing Services |
---|
2 | ################################## |
---|
3 | |
---|
4 | Introduction |
---|
5 | ============ |
---|
6 | |
---|
7 | The Symmetric Multiprocessing (SMP) support of the RTEMS 4.10.99.0 is |
---|
8 | available on |
---|
9 | |
---|
10 | - ARM, |
---|
11 | |
---|
12 | - PowerPC, and |
---|
13 | |
---|
14 | - SPARC. |
---|
15 | |
---|
16 | It must be explicitly enabled via the ``--enable-smp`` configure command |
---|
17 | line option. To enable SMP in the application configuration see `Enable SMP Support for Applications`_. The default |
---|
18 | scheduler for SMP applications supports up to 32 processors and is a global |
---|
19 | fixed priority scheduler, see also `Configuring Clustered Schedulers`_. For example applications see:file:`testsuites/smptests`. |
---|
20 | |
---|
21 | *WARNING: The SMP support in RTEMS is work in progress. Before you |
---|
22 | start using this RTEMS version for SMP ask on the RTEMS mailing list.* |
---|
23 | |
---|
24 | This chapter describes the services related to Symmetric Multiprocessing |
---|
25 | provided by RTEMS. |
---|
26 | |
---|
27 | The application level services currently provided are: |
---|
28 | |
---|
29 | - ``rtems_get_processor_count`` - Get processor count |
---|
30 | |
---|
31 | - ``rtems_get_current_processor`` - Get current processor index |
---|
32 | |
---|
33 | - ``rtems_scheduler_ident`` - Get ID of a scheduler |
---|
34 | |
---|
35 | - ``rtems_scheduler_get_processor_set`` - Get processor set of a scheduler |
---|
36 | |
---|
37 | - ``rtems_task_get_scheduler`` - Get scheduler of a task |
---|
38 | |
---|
39 | - ``rtems_task_set_scheduler`` - Set scheduler of a task |
---|
40 | |
---|
41 | - ``rtems_task_get_affinity`` - Get task processor affinity |
---|
42 | |
---|
43 | - ``rtems_task_set_affinity`` - Set task processor affinity |
---|
44 | |
---|
45 | Background |
---|
46 | ========== |
---|
47 | |
---|
48 | Uniprocessor versus SMP Parallelism |
---|
49 | ----------------------------------- |
---|
50 | |
---|
51 | Uniprocessor systems have long been used in embedded systems. In this hardware |
---|
52 | model, there are some system execution characteristics which have long been |
---|
53 | taken for granted: |
---|
54 | |
---|
55 | - one task executes at a time |
---|
56 | |
---|
57 | - hardware events result in interrupts |
---|
58 | |
---|
59 | There is no true parallelism. Even when interrupts appear to occur |
---|
60 | at the same time, they are processed in largely a serial fashion. |
---|
61 | This is true even when the interupt service routines are allowed to |
---|
62 | nest. From a tasking viewpoint, it is the responsibility of the real-time |
---|
63 | operatimg system to simulate parallelism by switching between tasks. |
---|
64 | These task switches occur in response to hardware interrupt events and explicit |
---|
65 | application events such as blocking for a resource or delaying. |
---|
66 | |
---|
67 | With symmetric multiprocessing, the presence of multiple processors |
---|
68 | allows for true concurrency and provides for cost-effective performance |
---|
69 | improvements. Uniprocessors tend to increase performance by increasing |
---|
70 | clock speed and complexity. This tends to lead to hot, power hungry |
---|
71 | microprocessors which are poorly suited for many embedded applications. |
---|
72 | |
---|
73 | The true concurrency is in sharp contrast to the single task and |
---|
74 | interrupt model of uniprocessor systems. This results in a fundamental |
---|
75 | change to uniprocessor system characteristics listed above. Developers |
---|
76 | are faced with a different set of characteristics which, in turn, break |
---|
77 | some existing assumptions and result in new challenges. In an SMP system |
---|
78 | with N processors, these are the new execution characteristics. |
---|
79 | |
---|
80 | - N tasks execute in parallel |
---|
81 | |
---|
82 | - hardware events result in interrupts |
---|
83 | |
---|
84 | There is true parallelism with a task executing on each processor and |
---|
85 | the possibility of interrupts occurring on each processor. Thus in contrast |
---|
86 | to their being one task and one interrupt to consider on a uniprocessor, |
---|
87 | there are N tasks and potentially N simultaneous interrupts to consider |
---|
88 | on an SMP system. |
---|
89 | |
---|
90 | This increase in hardware complexity and presence of true parallelism |
---|
91 | results in the application developer needing to be even more cautious |
---|
92 | about mutual exclusion and shared data access than in a uniprocessor |
---|
93 | embedded system. Race conditions that never or rarely happened when an |
---|
94 | application executed on a uniprocessor system, become much more likely |
---|
95 | due to multiple threads executing in parallel. On a uniprocessor system, |
---|
96 | these race conditions would only happen when a task switch occurred at |
---|
97 | just the wrong moment. Now there are N-1 tasks executing in parallel |
---|
98 | all the time and this results in many more opportunities for small |
---|
99 | windows in critical sections to be hit. |
---|
100 | |
---|
101 | Task Affinity |
---|
102 | ------------- |
---|
103 | .. index:: task affinity |
---|
104 | .. index:: thread affinity |
---|
105 | |
---|
106 | RTEMS provides services to manipulate the affinity of a task. Affinity |
---|
107 | is used to specify the subset of processors in an SMP system on which |
---|
108 | a particular task can execute. |
---|
109 | |
---|
110 | By default, tasks have an affinity which allows them to execute on any |
---|
111 | available processor. |
---|
112 | |
---|
113 | Task affinity is a possible feature to be supported by SMP-aware |
---|
114 | schedulers. However, only a subset of the available schedulers support |
---|
115 | affinity. Although the behavior is scheduler specific, if the scheduler |
---|
116 | does not support affinity, it is likely to ignore all attempts to set |
---|
117 | affinity. |
---|
118 | |
---|
119 | The scheduler with support for arbitary processor affinities uses a proof of |
---|
120 | concept implementation. See https://devel.rtems.org/ticket/2510. |
---|
121 | |
---|
122 | Task Migration |
---|
123 | -------------- |
---|
124 | .. index:: task migration |
---|
125 | .. index:: thread migration |
---|
126 | |
---|
127 | With more than one processor in the system tasks can migrate from one processor |
---|
128 | to another. There are three reasons why tasks migrate in RTEMS. |
---|
129 | |
---|
130 | - The scheduler changes explicitly via ``rtems_task_set_scheduler()`` or |
---|
131 | similar directives. |
---|
132 | |
---|
133 | - The task resumes execution after a blocking operation. On a priority |
---|
134 | based scheduler it will evict the lowest priority task currently assigned to a |
---|
135 | processor in the processor set managed by the scheduler instance. |
---|
136 | |
---|
137 | - The task moves temporarily to another scheduler instance due to locking |
---|
138 | protocols like *Migratory Priority Inheritance* or the*Multiprocessor Resource Sharing Protocol*. |
---|
139 | |
---|
140 | Task migration should be avoided so that the working set of a task can stay on |
---|
141 | the most local cache level. |
---|
142 | |
---|
143 | The current implementation of task migration in RTEMS has some implications |
---|
144 | with respect to the interrupt latency. It is crucial to preserve the system |
---|
145 | invariant that a task can execute on at most one processor in the system at a |
---|
146 | time. This is accomplished with a boolean indicator in the task context. The |
---|
147 | processor architecture specific low-level task context switch code will mark |
---|
148 | that a task context is no longer executing and waits that the heir context |
---|
149 | stopped execution before it restores the heir context and resumes execution of |
---|
150 | the heir task. So there is one point in time in which a processor is without a |
---|
151 | task. This is essential to avoid cyclic dependencies in case multiple tasks |
---|
152 | migrate at once. Otherwise some supervising entity is necessary to prevent |
---|
153 | life-locks. Such a global supervisor would lead to scalability problems so |
---|
154 | this approach is not used. Currently the thread dispatch is performed with |
---|
155 | interrupts disabled. So in case the heir task is currently executing on |
---|
156 | another processor then this prolongs the time of disabled interrupts since one |
---|
157 | processor has to wait for another processor to make progress. |
---|
158 | |
---|
159 | It is difficult to avoid this issue with the interrupt latency since interrupts |
---|
160 | normally store the context of the interrupted task on its stack. In case a |
---|
161 | task is marked as not executing we must not use its task stack to store such an |
---|
162 | interrupt context. We cannot use the heir stack before it stopped execution on |
---|
163 | another processor. So if we enable interrupts during this transition we have |
---|
164 | to provide an alternative task independent stack for this time frame. This |
---|
165 | issue needs further investigation. |
---|
166 | |
---|
167 | Clustered Scheduling |
---|
168 | -------------------- |
---|
169 | |
---|
170 | We have clustered scheduling in case the set of processors of a system is |
---|
171 | partitioned into non-empty pairwise-disjoint subsets. These subsets are called |
---|
172 | clusters. Clusters with a cardinality of one are partitions. Each cluster is |
---|
173 | owned by exactly one scheduler instance. |
---|
174 | |
---|
175 | Clustered scheduling helps to control the worst-case latencies in |
---|
176 | multi-processor systems, see *Brandenburg, Björn B.: Scheduling and |
---|
177 | Locking in Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf*. The goal is to |
---|
178 | reduce the amount of shared state in the system and thus prevention of lock |
---|
179 | contention. Modern multi-processor systems tend to have several layers of data |
---|
180 | and instruction caches. With clustered scheduling it is possible to honour the |
---|
181 | cache topology of a system and thus avoid expensive cache synchronization |
---|
182 | traffic. It is easy to implement. The problem is to provide synchronization |
---|
183 | primitives for inter-cluster synchronization (more than one cluster is involved |
---|
184 | in the synchronization process). In RTEMS there are currently four means |
---|
185 | available |
---|
186 | |
---|
187 | - events, |
---|
188 | |
---|
189 | - message queues, |
---|
190 | |
---|
191 | - semaphores using the `Priority Inheritance`_ |
---|
192 | protocol (priority boosting), and |
---|
193 | |
---|
194 | - semaphores using the `Multiprocessor Resource Sharing Protocol`_ (MrsP). |
---|
195 | |
---|
196 | The clustered scheduling approach enables separation of functions with |
---|
197 | real-time requirements and functions that profit from fairness and high |
---|
198 | throughput provided the scheduler instances are fully decoupled and adequate |
---|
199 | inter-cluster synchronization primitives are used. This is work in progress. |
---|
200 | |
---|
201 | For the configuration of clustered schedulers see `Configuring Clustered Schedulers`_. |
---|
202 | |
---|
203 | To set the scheduler of a task see `SCHEDULER_IDENT - Get ID of a scheduler`_ |
---|
204 | and `TASK_SET_SCHEDULER - Set scheduler of a task`_. |
---|
205 | |
---|
206 | Task Priority Queues |
---|
207 | -------------------- |
---|
208 | |
---|
209 | Due to the support for clustered scheduling the task priority queues need |
---|
210 | special attention. It makes no sense to compare the priority values of two |
---|
211 | different scheduler instances. Thus, it is not possible to simply use one |
---|
212 | plain priority queue for tasks of different scheduler instances. |
---|
213 | |
---|
214 | One solution to this problem is to use two levels of queues. The top level |
---|
215 | queue provides FIFO ordering and contains priority queues. Each priority queue |
---|
216 | is associated with a scheduler instance and contains only tasks of this |
---|
217 | scheduler instance. Tasks are enqueued in the priority queue corresponding to |
---|
218 | their scheduler instance. In case this priority queue was empty, then it is |
---|
219 | appended to the FIFO. To dequeue a task the highest priority task of the first |
---|
220 | priority queue in the FIFO is selected. Then the first priority queue is |
---|
221 | removed from the FIFO. In case the previously first priority queue is not |
---|
222 | empty, then it is appended to the FIFO. So there is FIFO fairness with respect |
---|
223 | to the highest priority task of each scheduler instances. See also *Brandenburg, Björn B.: A fully preemptive multiprocessor semaphore protocol for |
---|
224 | latency-sensitive real-time applications. In Proceedings of the 25th Euromicro |
---|
225 | Conference on Real-Time Systems (ECRTS 2013), pages 292âÂÂ302, 2013.http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf*. |
---|
226 | |
---|
227 | Such a two level queue may need a considerable amount of memory if fast enqueue |
---|
228 | and dequeue operations are desired (depends on the scheduler instance count). |
---|
229 | To mitigate this problem an approch of the FreeBSD kernel was implemented in |
---|
230 | RTEMS. We have the invariant that a task can be enqueued on at most one task |
---|
231 | queue. Thus, we need only as many queues as we have tasks. Each task is |
---|
232 | equipped with spare task queue which it can give to an object on demand. The |
---|
233 | task queue uses a dedicated memory space independent of the other memory used |
---|
234 | for the task itself. In case a task needs to block, then there are two options |
---|
235 | |
---|
236 | - the object already has task queue, then the task enqueues itself to this |
---|
237 | already present queue and the spare task queue of the task is added to a list |
---|
238 | of free queues for this object, or |
---|
239 | |
---|
240 | - otherwise, then the queue of the task is given to the object and the task |
---|
241 | enqueues itself to this queue. |
---|
242 | |
---|
243 | In case the task is dequeued, then there are two options |
---|
244 | |
---|
245 | - the task is the last task on the queue, then it removes this queue from |
---|
246 | the object and reclaims it for its own purpose, or |
---|
247 | |
---|
248 | - otherwise, then the task removes one queue from the free list of the |
---|
249 | object and reclaims it for its own purpose. |
---|
250 | |
---|
251 | Since there are usually more objects than tasks, this actually reduces the |
---|
252 | memory demands. In addition the objects contain only a pointer to the task |
---|
253 | queue structure. This helps to hide implementation details and makes it |
---|
254 | possible to use self-contained synchronization objects in Newlib and GCC (C++ |
---|
255 | and OpenMP run-time support). |
---|
256 | |
---|
257 | Scheduler Helping Protocol |
---|
258 | -------------------------- |
---|
259 | |
---|
260 | The scheduler provides a helping protocol to support locking protocols like*Migratory Priority Inheritance* or the *Multiprocessor Resource |
---|
261 | Sharing Protocol*. Each ready task can use at least one scheduler node at a |
---|
262 | time to gain access to a processor. Each scheduler node has an owner, a user |
---|
263 | and an optional idle task. The owner of a scheduler node is determined a task |
---|
264 | creation and never changes during the life time of a scheduler node. The user |
---|
265 | of a scheduler node may change due to the scheduler helping protocol. A |
---|
266 | scheduler node is in one of the four scheduler help states: |
---|
267 | |
---|
268 | :dfn:`help yourself` |
---|
269 | This scheduler node is solely used by the owner task. This task owns no |
---|
270 | resources using a helping protocol and thus does not take part in the scheduler |
---|
271 | helping protocol. No help will be provided for other tasks. |
---|
272 | |
---|
273 | :dfn:`help active owner` |
---|
274 | This scheduler node is owned by a task actively owning a resource and can be |
---|
275 | used to help out tasks. |
---|
276 | In case this scheduler node changes its state from ready to scheduled and the |
---|
277 | task executes using another node, then an idle task will be provided as a user |
---|
278 | of this node to temporarily execute on behalf of the owner task. Thus lower |
---|
279 | priority tasks are denied access to the processors of this scheduler instance. |
---|
280 | In case a task actively owning a resource performs a blocking operation, then |
---|
281 | an idle task will be used also in case this node is in the scheduled state. |
---|
282 | |
---|
283 | :dfn:`help active rival` |
---|
284 | This scheduler node is owned by a task actively obtaining a resource currently |
---|
285 | owned by another task and can be used to help out tasks. |
---|
286 | The task owning this node is ready and will give away its processor in case the |
---|
287 | task owning the resource asks for help. |
---|
288 | |
---|
289 | :dfn:`help passive` |
---|
290 | This scheduler node is owned by a task obtaining a resource currently owned by |
---|
291 | another task and can be used to help out tasks. |
---|
292 | The task owning this node is blocked. |
---|
293 | |
---|
294 | The following scheduler operations return a task in need for help |
---|
295 | |
---|
296 | - unblock, |
---|
297 | |
---|
298 | - change priority, |
---|
299 | |
---|
300 | - yield, and |
---|
301 | |
---|
302 | - ask for help. |
---|
303 | |
---|
304 | A task in need for help is a task that encounters a scheduler state change from |
---|
305 | scheduled to ready (this is a pre-emption by a higher priority task) or a task |
---|
306 | that cannot be scheduled in an unblock operation. Such a task can ask tasks |
---|
307 | which depend on resources owned by this task for help. |
---|
308 | |
---|
309 | In case it is not possible to schedule a task in need for help, then the |
---|
310 | scheduler nodes available for the task will be placed into the set of ready |
---|
311 | scheduler nodes of the corresponding scheduler instances. Once a state change |
---|
312 | from ready to scheduled happens for one of scheduler nodes it will be used to |
---|
313 | schedule the task in need for help. |
---|
314 | |
---|
315 | The ask for help scheduler operation is used to help tasks in need for help |
---|
316 | returned by the operations mentioned above. This operation is also used in |
---|
317 | case the root of a resource sub-tree owned by a task changes. |
---|
318 | |
---|
319 | The run-time of the ask for help procedures depend on the size of the resource |
---|
320 | tree of the task needing help and other resource trees in case tasks in need |
---|
321 | for help are produced during this operation. Thus the worst-case latency in |
---|
322 | the system depends on the maximum resource tree size of the application. |
---|
323 | |
---|
324 | Critical Section Techniques and SMP |
---|
325 | ----------------------------------- |
---|
326 | |
---|
327 | As discussed earlier, SMP systems have opportunities for true parallelism |
---|
328 | which was not possible on uniprocessor systems. Consequently, multiple |
---|
329 | techniques that provided adequate critical sections on uniprocessor |
---|
330 | systems are unsafe on SMP systems. In this section, some of these |
---|
331 | unsafe techniques will be discussed. |
---|
332 | |
---|
333 | In general, applications must use proper operating system provided mutual |
---|
334 | exclusion mechanisms to ensure correct behavior. This primarily means |
---|
335 | the use of binary semaphores or mutexes to implement critical sections. |
---|
336 | |
---|
337 | Disable Interrupts and Interrupt Locks |
---|
338 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
339 | |
---|
340 | A low overhead means to ensure mutual exclusion in uni-processor configurations |
---|
341 | is to disable interrupts around a critical section. This is commonly used in |
---|
342 | device driver code and throughout the operating system core. On SMP |
---|
343 | configurations, however, disabling the interrupts on one processor has no |
---|
344 | effect on other processors. So, this is insufficient to ensure system wide |
---|
345 | mutual exclusion. The macros |
---|
346 | |
---|
347 | - ``rtems_interrupt_disable()``, |
---|
348 | |
---|
349 | - ``rtems_interrupt_enable()``, and |
---|
350 | |
---|
351 | - ``rtems_interrupt_flush()`` |
---|
352 | |
---|
353 | are disabled on SMP configurations and its use will lead to compiler warnings |
---|
354 | and linker errors. In the unlikely case that interrupts must be disabled on |
---|
355 | the current processor, then the |
---|
356 | |
---|
357 | - ``rtems_interrupt_local_disable()``, and |
---|
358 | |
---|
359 | - ``rtems_interrupt_local_enable()`` |
---|
360 | |
---|
361 | macros are now available in all configurations. |
---|
362 | |
---|
363 | Since disabling of interrupts is not enough to ensure system wide mutual |
---|
364 | exclusion on SMP, a new low-level synchronization primitive was added - the |
---|
365 | interrupt locks. They are a simple API layer on top of the SMP locks used for |
---|
366 | low-level synchronization in the operating system core. Currently they are |
---|
367 | implemented as a ticket lock. On uni-processor configurations they degenerate |
---|
368 | to simple interrupt disable/enable sequences. It is disallowed to acquire a |
---|
369 | single interrupt lock in a nested way. This will result in an infinite loop |
---|
370 | with interrupts disabled. While converting legacy code to interrupt locks care |
---|
371 | must be taken to avoid this situation. |
---|
372 | .. code:: c |
---|
373 | |
---|
374 | void legacy_code_with_interrupt_disable_enable( void ) |
---|
375 | { |
---|
376 | rtems_interrupt_level level; |
---|
377 | rtems_interrupt_disable( level ); |
---|
378 | /* Some critical stuff \*/ |
---|
379 | rtems_interrupt_enable( level ); |
---|
380 | } |
---|
381 | RTEMS_INTERRUPT_LOCK_DEFINE( static, lock, "Name" ) |
---|
382 | void smp_ready_code_with_interrupt_lock( void ) |
---|
383 | { |
---|
384 | rtems_interrupt_lock_context lock_context; |
---|
385 | rtems_interrupt_lock_acquire( &lock, &lock_context ); |
---|
386 | /* Some critical stuff \*/ |
---|
387 | rtems_interrupt_lock_release( &lock, &lock_context ); |
---|
388 | } |
---|
389 | |
---|
390 | The ``rtems_interrupt_lock`` structure is empty on uni-processor |
---|
391 | configurations. Empty structures have a different size in C |
---|
392 | (implementation-defined, zero in case of GCC) and C++ (implementation-defined |
---|
393 | non-zero value, one in case of GCC). Thus the``RTEMS_INTERRUPT_LOCK_DECLARE()``, ``RTEMS_INTERRUPT_LOCK_DEFINE()``,``RTEMS_INTERRUPT_LOCK_MEMBER()``, and``RTEMS_INTERRUPT_LOCK_REFERENCE()`` macros are provided to ensure ABI |
---|
394 | compatibility. |
---|
395 | |
---|
396 | Highest Priority Task Assumption |
---|
397 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
398 | |
---|
399 | On a uniprocessor system, it is safe to assume that when the highest |
---|
400 | priority task in an application executes, it will execute without being |
---|
401 | preempted until it voluntarily blocks. Interrupts may occur while it is |
---|
402 | executing, but there will be no context switch to another task unless |
---|
403 | the highest priority task voluntarily initiates it. |
---|
404 | |
---|
405 | Given the assumption that no other tasks will have their execution |
---|
406 | interleaved with the highest priority task, it is possible for this |
---|
407 | task to be constructed such that it does not need to acquire a binary |
---|
408 | semaphore or mutex for protected access to shared data. |
---|
409 | |
---|
410 | In an SMP system, it cannot be assumed there will never be a single task |
---|
411 | executing. It should be assumed that every processor is executing another |
---|
412 | application task. Further, those tasks will be ones which would not have |
---|
413 | been executed in a uniprocessor configuration and should be assumed to |
---|
414 | have data synchronization conflicts with what was formerly the highest |
---|
415 | priority task which executed without conflict. |
---|
416 | |
---|
417 | Disable Preemption |
---|
418 | ~~~~~~~~~~~~~~~~~~ |
---|
419 | |
---|
420 | On a uniprocessor system, disabling preemption in a task is very similar |
---|
421 | to making the highest priority task assumption. While preemption is |
---|
422 | disabled, no task context switches will occur unless the task initiates |
---|
423 | them voluntarily. And, just as with the highest priority task assumption, |
---|
424 | there are N-1 processors also running tasks. Thus the assumption that no |
---|
425 | other tasks will run while the task has preemption disabled is violated. |
---|
426 | |
---|
427 | Task Unique Data and SMP |
---|
428 | ------------------------ |
---|
429 | |
---|
430 | Per task variables are a service commonly provided by real-time operating |
---|
431 | systems for application use. They work by allowing the application |
---|
432 | to specify a location in memory (typically a ``void *``) which is |
---|
433 | logically added to the context of a task. On each task switch, the |
---|
434 | location in memory is stored and each task can have a unique value in |
---|
435 | the same memory location. This memory location is directly accessed as a |
---|
436 | variable in a program. |
---|
437 | |
---|
438 | This works well in a uniprocessor environment because there is one task |
---|
439 | executing and one memory location containing a task-specific value. But |
---|
440 | it is fundamentally broken on an SMP system because there are always N |
---|
441 | tasks executing. With only one location in memory, N-1 tasks will not |
---|
442 | have the correct value. |
---|
443 | |
---|
444 | This paradigm for providing task unique data values is fundamentally |
---|
445 | broken on SMP systems. |
---|
446 | |
---|
447 | Classic API Per Task Variables |
---|
448 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
---|
449 | |
---|
450 | The Classic API provides three directives to support per task variables. These are: |
---|
451 | |
---|
452 | - ``rtems.task_variable_add`` - Associate per task variable |
---|
453 | |
---|
454 | - ``rtems.task_variable_get`` - Obtain value of a a per task variable |
---|
455 | |
---|
456 | - ``rtems.task_variable_delete`` - Remove per task variable |
---|
457 | |
---|
458 | As task variables are unsafe for use on SMP systems, the use of these services |
---|
459 | must be eliminated in all software that is to be used in an SMP environment. |
---|
460 | The task variables API is disabled on SMP. Its use will lead to compile-time |
---|
461 | and link-time errors. It is recommended that the application developer consider |
---|
462 | the use of POSIX Keys or Thread Local Storage (TLS). POSIX Keys are available |
---|
463 | in all RTEMS configurations. For the availablity of TLS on a particular |
---|
464 | architecture please consult the *RTEMS CPU Architecture Supplement*. |
---|
465 | |
---|
466 | The only remaining user of task variables in the RTEMS code base is the Ada |
---|
467 | support. So basically Ada is not available on RTEMS SMP. |
---|
468 | |
---|
469 | OpenMP |
---|
470 | ------ |
---|
471 | |
---|
472 | OpenMP support for RTEMS is available via the GCC provided libgomp. There is |
---|
473 | libgomp support for RTEMS in the POSIX configuration of libgomp since GCC 4.9 |
---|
474 | (requires a Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a |
---|
475 | Newlib snapshot after 2015-07-30 for <sys/lock.h> provided self-contained |
---|
476 | synchronization objects) there is a specialized libgomp configuration for RTEMS |
---|
477 | which offers a significantly better performance compared to the POSIX |
---|
478 | configuration of libgomp. In addition application configurable thread pools |
---|
479 | for each scheduler instance are available in GCC 6.1 or later. |
---|
480 | |
---|
481 | The run-time configuration of libgomp is done via environment variables |
---|
482 | documented in the `libgomp |
---|
483 | manual <https://gcc.gnu.org/onlinedocs/libgomp/>`_. The environment variables are evaluated in a constructor function |
---|
484 | which executes in the context of the first initialization task before the |
---|
485 | actual initialization task function is called (just like a global C++ |
---|
486 | constructor). To set application specific values, a higher priority |
---|
487 | constructor function must be used to set up the environment variables. |
---|
488 | .. code:: c |
---|
489 | |
---|
490 | #include <stdlib.h> |
---|
491 | void __attribute__((constructor(1000))) config_libgomp( void ) |
---|
492 | { |
---|
493 | setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 ); |
---|
494 | setenv( "GOMP_SPINCOUNT", "30000", 1 ); |
---|
495 | setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@SCHD", 1 ); |
---|
496 | } |
---|
497 | |
---|
498 | The environment variable ``GOMP_RTEMS_THREAD_POOLS`` is RTEMS-specific. It |
---|
499 | determines the thread pools for each scheduler instance. The format for``GOMP_RTEMS_THREAD_POOLS`` is a list of optional``<thread-pool-count>[$<priority>]@<scheduler-name>`` configurations |
---|
500 | separated by ``:`` where: |
---|
501 | |
---|
502 | - ``<thread-pool-count>`` is the thread pool count for this scheduler |
---|
503 | instance. |
---|
504 | |
---|
505 | - ``$<priority>`` is an optional priority for the worker threads of a |
---|
506 | thread pool according to ``pthread_setschedparam``. In case a priority |
---|
507 | value is omitted, then a worker thread will inherit the priority of the OpenMP |
---|
508 | master thread that created it. The priority of the worker thread is not |
---|
509 | changed by libgomp after creation, even if a new OpenMP master thread using the |
---|
510 | worker has a different priority. |
---|
511 | |
---|
512 | - ``@<scheduler-name>`` is the scheduler instance name according to the |
---|
513 | RTEMS application configuration. |
---|
514 | |
---|
515 | In case no thread pool configuration is specified for a scheduler instance, |
---|
516 | then each OpenMP master thread of this scheduler instance will use its own |
---|
517 | dynamically allocated thread pool. To limit the worker thread count of the |
---|
518 | thread pools, each OpenMP master thread must call ``omp_set_num_threads``. |
---|
519 | |
---|
520 | Lets suppose we have three scheduler instances ``IO``, ``WRK0``, and``WRK1`` with ``GOMP_RTEMS_THREAD_POOLS`` set to``"1@WRK0:3$4@WRK1"``. Then there are no thread pool restrictions for |
---|
521 | scheduler instance ``IO``. In the scheduler instance ``WRK0`` there is |
---|
522 | one thread pool available. Since no priority is specified for this scheduler |
---|
523 | instance, the worker thread inherits the priority of the OpenMP master thread |
---|
524 | that created it. In the scheduler instance ``WRK1`` there are three thread |
---|
525 | pools available and their worker threads run at priority four. |
---|
526 | |
---|
527 | Thread Dispatch Details |
---|
528 | ----------------------- |
---|
529 | |
---|
530 | This section gives background information to developers interested in the |
---|
531 | interrupt latencies introduced by thread dispatching. A thread dispatch |
---|
532 | consists of all work which must be done to stop the currently executing thread |
---|
533 | on a processor and hand over this processor to an heir thread. |
---|
534 | |
---|
535 | On SMP systems, scheduling decisions on one processor must be propagated to |
---|
536 | other processors through inter-processor interrupts. So, a thread dispatch |
---|
537 | which must be carried out on another processor happens not instantaneous. Thus |
---|
538 | several thread dispatch requests might be in the air and it is possible that |
---|
539 | some of them may be out of date before the corresponding processor has time to |
---|
540 | deal with them. The thread dispatch mechanism uses three per-processor |
---|
541 | variables, |
---|
542 | |
---|
543 | - the executing thread, |
---|
544 | |
---|
545 | - the heir thread, and |
---|
546 | |
---|
547 | - an boolean flag indicating if a thread dispatch is necessary or not. |
---|
548 | |
---|
549 | Updates of the heir thread and the thread dispatch necessary indicator are |
---|
550 | synchronized via explicit memory barriers without the use of locks. A thread |
---|
551 | can be an heir thread on at most one processor in the system. The thread context |
---|
552 | is protected by a TTAS lock embedded in the context to ensure that it is used |
---|
553 | on at most one processor at a time. The thread post-switch actions use a |
---|
554 | per-processor lock. This implementation turned out to be quite efficient and |
---|
555 | no lock contention was observed in the test suite. |
---|
556 | |
---|
557 | The current implementation of thread dispatching has some implications with |
---|
558 | respect to the interrupt latency. It is crucial to preserve the system |
---|
559 | invariant that a thread can execute on at most one processor in the system at a |
---|
560 | time. This is accomplished with a boolean indicator in the thread context. |
---|
561 | The processor architecture specific context switch code will mark that a thread |
---|
562 | context is no longer executing and waits that the heir context stopped |
---|
563 | execution before it restores the heir context and resumes execution of the heir |
---|
564 | thread (the boolean indicator is basically a TTAS lock). So, there is one |
---|
565 | point in time in which a processor is without a thread. This is essential to |
---|
566 | avoid cyclic dependencies in case multiple threads migrate at once. Otherwise |
---|
567 | some supervising entity is necessary to prevent deadlocks. Such a global |
---|
568 | supervisor would lead to scalability problems so this approach is not used. |
---|
569 | Currently the context switch is performed with interrupts disabled. Thus in |
---|
570 | case the heir thread is currently executing on another processor, the time of |
---|
571 | disabled interrupts is prolonged since one processor has to wait for another |
---|
572 | processor to make progress. |
---|
573 | |
---|
574 | It is difficult to avoid this issue with the interrupt latency since interrupts |
---|
575 | normally store the context of the interrupted thread on its stack. In case a |
---|
576 | thread is marked as not executing, we must not use its thread stack to store |
---|
577 | such an interrupt context. We cannot use the heir stack before it stopped |
---|
578 | execution on another processor. If we enable interrupts during this |
---|
579 | transition, then we have to provide an alternative thread independent stack for |
---|
580 | interrupts in this time frame. This issue needs further investigation. |
---|
581 | |
---|
582 | The problematic situation occurs in case we have a thread which executes with |
---|
583 | thread dispatching disabled and should execute on another processor (e.g. it is |
---|
584 | an heir thread on another processor). In this case the interrupts on this |
---|
585 | other processor are disabled until the thread enables thread dispatching and |
---|
586 | starts the thread dispatch sequence. The scheduler (an exception is the |
---|
587 | scheduler with thread processor affinity support) tries to avoid such a |
---|
588 | situation and checks if a new scheduled thread already executes on a processor. |
---|
589 | In case the assigned processor differs from the processor on which the thread |
---|
590 | already executes and this processor is a member of the processor set managed by |
---|
591 | this scheduler instance, it will reassign the processors to keep the already |
---|
592 | executing thread in place. Therefore normal scheduler requests will not lead |
---|
593 | to such a situation. Explicit thread migration requests, however, can lead to |
---|
594 | this situation. Explicit thread migrations may occur due to the scheduler |
---|
595 | helping protocol or explicit scheduler instance changes. The situation can |
---|
596 | also be provoked by interrupts which suspend and resume threads multiple times |
---|
597 | and produce stale asynchronous thread dispatch requests in the system. |
---|
598 | |
---|
599 | Operations |
---|
600 | ========== |
---|
601 | |
---|
602 | Setting Affinity to a Single Processor |
---|
603 | -------------------------------------- |
---|
604 | |
---|
605 | On some embedded applications targeting SMP systems, it may be beneficial to |
---|
606 | lock individual tasks to specific processors. In this way, one can designate a |
---|
607 | processor for I/O tasks, another for computation, etc.. The following |
---|
608 | illustrates the code sequence necessary to assign a task an affinity for |
---|
609 | processor with index ``processor_index``. |
---|
610 | .. code:: c |
---|
611 | |
---|
612 | #include <rtems.h> |
---|
613 | #include <assert.h> |
---|
614 | void pin_to_processor(rtems_id task_id, int processor_index) |
---|
615 | { |
---|
616 | rtems_status_code sc; |
---|
617 | cpu_set_t cpuset; |
---|
618 | CPU_ZERO(&cpuset); |
---|
619 | CPU_SET(processor_index, &cpuset); |
---|
620 | sc = rtems_task_set_affinity(task_id, sizeof(cpuset), &cpuset); |
---|
621 | assert(sc == RTEMS_SUCCESSFUL); |
---|
622 | } |
---|
623 | |
---|
624 | It is important to note that the ``cpuset`` is not validated until the``rtems.task_set_affinity`` call is made. At that point, |
---|
625 | it is validated against the current system configuration. |
---|
626 | |
---|
627 | Directives |
---|
628 | ========== |
---|
629 | |
---|
630 | This section details the symmetric multiprocessing services. A subsection |
---|
631 | is dedicated to each of these services and describes the calling sequence, |
---|
632 | related constants, usage, and status codes. |
---|
633 | |
---|
634 | .. COMMENT: rtems_get_processor_count |
---|
635 | |
---|
636 | GET_PROCESSOR_COUNT - Get processor count |
---|
637 | ----------------------------------------- |
---|
638 | |
---|
639 | **CALLING SEQUENCE:** |
---|
640 | |
---|
641 | **DIRECTIVE STATUS CODES:** |
---|
642 | |
---|
643 | The count of processors in the system. |
---|
644 | |
---|
645 | **DESCRIPTION:** |
---|
646 | |
---|
647 | On uni-processor configurations a value of one will be returned. |
---|
648 | |
---|
649 | On SMP configurations this returns the value of a global variable set during |
---|
650 | system initialization to indicate the count of utilized processors. The |
---|
651 | processor count depends on the physically or virtually available processors and |
---|
652 | application configuration. The value will always be less than or equal to the |
---|
653 | maximum count of application configured processors. |
---|
654 | |
---|
655 | **NOTES:** |
---|
656 | |
---|
657 | None. |
---|
658 | |
---|
659 | .. COMMENT: rtems_get_current_processor |
---|
660 | |
---|
661 | GET_CURRENT_PROCESSOR - Get current processor index |
---|
662 | --------------------------------------------------- |
---|
663 | |
---|
664 | **CALLING SEQUENCE:** |
---|
665 | |
---|
666 | **DIRECTIVE STATUS CODES:** |
---|
667 | |
---|
668 | The index of the current processor. |
---|
669 | |
---|
670 | **DESCRIPTION:** |
---|
671 | |
---|
672 | On uni-processor configurations a value of zero will be returned. |
---|
673 | |
---|
674 | On SMP configurations an architecture specific method is used to obtain the |
---|
675 | index of the current processor in the system. The set of processor indices is |
---|
676 | the range of integers starting with zero up to the processor count minus one. |
---|
677 | |
---|
678 | Outside of sections with disabled thread dispatching the current processor |
---|
679 | index may change after every instruction since the thread may migrate from one |
---|
680 | processor to another. Sections with disabled interrupts are sections with |
---|
681 | thread dispatching disabled. |
---|
682 | |
---|
683 | **NOTES:** |
---|
684 | |
---|
685 | None. |
---|
686 | |
---|
687 | .. COMMENT: rtems_scheduler_ident |
---|
688 | |
---|
689 | |
---|
690 | SCHEDULER_IDENT - Get ID of a scheduler |
---|
691 | --------------------------------------- |
---|
692 | |
---|
693 | **CALLING SEQUENCE:** |
---|
694 | |
---|
695 | **DIRECTIVE STATUS CODES:** |
---|
696 | |
---|
697 | ``RTEMS.SUCCESSFUL`` - successful operation |
---|
698 | ``RTEMS.INVALID_ADDRESS`` - ``id`` is NULL |
---|
699 | ``RTEMS.INVALID_NAME`` - invalid scheduler name |
---|
700 | ``RTEMS.UNSATISFIED`` - - a scheduler with this name exists, but |
---|
701 | the processor set of this scheduler is empty |
---|
702 | |
---|
703 | **DESCRIPTION:** |
---|
704 | |
---|
705 | Identifies a scheduler by its name. The scheduler name is determined by the |
---|
706 | scheduler configuration. See `Configuring Clustered Schedulers`_. |
---|
707 | |
---|
708 | **NOTES:** |
---|
709 | |
---|
710 | None. |
---|
711 | |
---|
712 | .. COMMENT: rtems_scheduler_get_processor_set |
---|
713 | |
---|
714 | SCHEDULER_GET_PROCESSOR_SET - Get processor set of a scheduler |
---|
715 | -------------------------------------------------------------- |
---|
716 | |
---|
717 | **CALLING SEQUENCE:** |
---|
718 | |
---|
719 | **DIRECTIVE STATUS CODES:** |
---|
720 | |
---|
721 | ``RTEMS.SUCCESSFUL`` - successful operation |
---|
722 | ``RTEMS.INVALID_ADDRESS`` - ``cpuset`` is NULL |
---|
723 | ``RTEMS.INVALID_ID`` - invalid scheduler id |
---|
724 | ``RTEMS.INVALID_NUMBER`` - the affinity set buffer is too small for |
---|
725 | set of processors owned by the scheduler |
---|
726 | |
---|
727 | **DESCRIPTION:** |
---|
728 | |
---|
729 | Returns the processor set owned by the scheduler in ``cpuset``. A set bit |
---|
730 | in the processor set means that this processor is owned by the scheduler and a |
---|
731 | cleared bit means the opposite. |
---|
732 | |
---|
733 | **NOTES:** |
---|
734 | |
---|
735 | None. |
---|
736 | |
---|
737 | .. COMMENT: rtems_task_get_scheduler |
---|
738 | |
---|
739 | TASK_GET_SCHEDULER - Get scheduler of a task |
---|
740 | -------------------------------------------- |
---|
741 | |
---|
742 | **CALLING SEQUENCE:** |
---|
743 | |
---|
744 | **DIRECTIVE STATUS CODES:** |
---|
745 | |
---|
746 | ``RTEMS.SUCCESSFUL`` - successful operation |
---|
747 | ``RTEMS.INVALID_ADDRESS`` - ``scheduler_id`` is NULL |
---|
748 | ``RTEMS.INVALID_ID`` - invalid task id |
---|
749 | |
---|
750 | **DESCRIPTION:** |
---|
751 | |
---|
752 | Returns the scheduler identifier of a task identified by ``task_id`` in``scheduler_id``. |
---|
753 | |
---|
754 | **NOTES:** |
---|
755 | |
---|
756 | None. |
---|
757 | |
---|
758 | .. COMMENT: rtems_task_set_scheduler |
---|
759 | |
---|
760 | |
---|
761 | TASK_SET_SCHEDULER - Set scheduler of a task |
---|
762 | -------------------------------------------- |
---|
763 | |
---|
764 | **CALLING SEQUENCE:** |
---|
765 | |
---|
766 | **DIRECTIVE STATUS CODES:** |
---|
767 | |
---|
768 | ``RTEMS.SUCCESSFUL`` - successful operation |
---|
769 | ``RTEMS.INVALID_ID`` - invalid task or scheduler id |
---|
770 | ``RTEMS.INCORRECT_STATE`` - the task is in the wrong state to |
---|
771 | perform a scheduler change |
---|
772 | |
---|
773 | **DESCRIPTION:** |
---|
774 | |
---|
775 | Sets the scheduler of a task identified by ``task_id`` to the scheduler |
---|
776 | identified by ``scheduler_id``. The scheduler of a task is initialized to |
---|
777 | the scheduler of the task that created it. |
---|
778 | |
---|
779 | **NOTES:** |
---|
780 | |
---|
781 | None. |
---|
782 | |
---|
783 | **EXAMPLE:** |
---|
784 | |
---|
785 | .. code:: c |
---|
786 | |
---|
787 | #include <rtems.h> |
---|
788 | #include <assert.h> |
---|
789 | void task(rtems_task_argument arg); |
---|
790 | void example(void) |
---|
791 | { |
---|
792 | rtems_status_code sc; |
---|
793 | rtems_id task_id; |
---|
794 | rtems_id scheduler_id; |
---|
795 | rtems_name scheduler_name; |
---|
796 | scheduler_name = rtems_build_name('W', 'O', 'R', 'K'); |
---|
797 | sc = rtems_scheduler_ident(scheduler_name, &scheduler_id); |
---|
798 | assert(sc == RTEMS_SUCCESSFUL); |
---|
799 | sc = rtems_task_create( |
---|
800 | rtems_build_name('T', 'A', 'S', 'K'), |
---|
801 | 1, |
---|
802 | RTEMS_MINIMUM_STACK_SIZE, |
---|
803 | RTEMS_DEFAULT_MODES, |
---|
804 | RTEMS_DEFAULT_ATTRIBUTES, |
---|
805 | &task_id |
---|
806 | ); |
---|
807 | assert(sc == RTEMS_SUCCESSFUL); |
---|
808 | sc = rtems_task_set_scheduler(task_id, scheduler_id); |
---|
809 | assert(sc == RTEMS_SUCCESSFUL); |
---|
810 | sc = rtems_task_start(task_id, task, 0); |
---|
811 | assert(sc == RTEMS_SUCCESSFUL); |
---|
812 | } |
---|
813 | |
---|
814 | .. COMMENT: rtems_task_get_affinity |
---|
815 | |
---|
816 | TASK_GET_AFFINITY - Get task processor affinity |
---|
817 | ----------------------------------------------- |
---|
818 | |
---|
819 | **CALLING SEQUENCE:** |
---|
820 | |
---|
821 | **DIRECTIVE STATUS CODES:** |
---|
822 | |
---|
823 | ``RTEMS.SUCCESSFUL`` - successful operation |
---|
824 | ``RTEMS.INVALID_ADDRESS`` - ``cpuset`` is NULL |
---|
825 | ``RTEMS.INVALID_ID`` - invalid task id |
---|
826 | ``RTEMS.INVALID_NUMBER`` - the affinity set buffer is too small for |
---|
827 | the current processor affinity set of the task |
---|
828 | |
---|
829 | **DESCRIPTION:** |
---|
830 | |
---|
831 | Returns the current processor affinity set of the task in ``cpuset``. A set |
---|
832 | bit in the affinity set means that the task can execute on this processor and a |
---|
833 | cleared bit means the opposite. |
---|
834 | |
---|
835 | **NOTES:** |
---|
836 | |
---|
837 | None. |
---|
838 | |
---|
839 | .. COMMENT: rtems_task_set_affinity |
---|
840 | |
---|
841 | TASK_SET_AFFINITY - Set task processor affinity |
---|
842 | ----------------------------------------------- |
---|
843 | |
---|
844 | **CALLING SEQUENCE:** |
---|
845 | |
---|
846 | **DIRECTIVE STATUS CODES:** |
---|
847 | |
---|
848 | ``RTEMS.SUCCESSFUL`` - successful operation |
---|
849 | ``RTEMS.INVALID_ADDRESS`` - ``cpuset`` is NULL |
---|
850 | ``RTEMS.INVALID_ID`` - invalid task id |
---|
851 | ``RTEMS.INVALID_NUMBER`` - invalid processor affinity set |
---|
852 | |
---|
853 | **DESCRIPTION:** |
---|
854 | |
---|
855 | Sets the processor affinity set for the task specified by ``cpuset``. A set |
---|
856 | bit in the affinity set means that the task can execute on this processor and a |
---|
857 | cleared bit means the opposite. |
---|
858 | |
---|
859 | **NOTES:** |
---|
860 | |
---|
861 | This function will not change the scheduler of the task. The intersection of |
---|
862 | the processor affinity set and the set of processors owned by the scheduler of |
---|
863 | the task must be non-empty. It is not an error if the processor affinity set |
---|
864 | contains processors that are not part of the set of processors owned by the |
---|
865 | scheduler instance of the task. A task will simply not run under normal |
---|
866 | circumstances on these processors since the scheduler ignores them. Some |
---|
867 | locking protocols may temporarily use processors that are not included in the |
---|
868 | processor affinity set of the task. It is also not an error if the processor |
---|
869 | affinity set contains processors that are not part of the system. |
---|
870 | |
---|
871 | .. COMMENT: COPYRIGHT (c) 2011,2015 |
---|
872 | |
---|
873 | .. COMMENT: Aeroflex Gaisler AB |
---|
874 | |
---|
875 | .. COMMENT: All rights reserved. |
---|
876 | |
---|