On 17/07/15 03:39, Cyrille Artho wrote:
Note that the lock only protects against direct accesses to the thread priority. If other code relies on the fact that the change is still current further down, then we may have an "atomicity race" (as it's sometimes called) or causality problem (another name for this). We are currently trying out ways to avoid any such issues, without using too many locks.
Please review the _Thread_Change_priority() function and Thread_Lock_control carefully. You may have a look at _Thread_queue_Enqueue_critical() and search for _Thread_Lock_set() for example.
-- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
