forked from Imagelibrary/rtems
9bfad8cd51
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.
This is the Real-Time Executive for Multiprocessing Systems (RTEMS). The version number for this software is indicated in the VERSION file. See the documentation manuals in doc/ with daily builds available online at http://rtems.org/onlinedocs/doc-current/share/rtems/html/ and released builds at http://www.rtems.org/onlinedocs/releases/ for information on building, installing, and using RTEMS. The INSTALL file tells you to come back here. See the RTEMS Wiki at http://devel.rtems.org for community knowledge and tutorials. RTEMS Doxygen available at http://www.rtems.org/onlinedocs/doxygen/cpukit/html The RTEMS Project maintains mailing lists which are used for most discussions: * For general-purpose questions related to using RTEMS, use the rtems-users ml: https://lists.rtems.org/mailman/listinfo/users * For questions and discussion related to development of RTEMS, use the rtems-devel ml: https://lists.rtems.org/mailman/listinfo/devel See https://devel.rtems.org/ to view existing or file a new issue report ticket.