Yes I was looking for same present in Thread_Lock_control. I might some how missed it while going through Thread_Control_struct. Thanks. Then as lock is present then I suppose we might have certainly taken care of data race conditions.
Thanks, Saurabh Gadia On Thu, Jul 16, 2015 at 12:19 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > > > On 16/07/15 01:49, Saurabh Gadia wrote: > >> Hi, >> Is there any explicit locking to avoid data races condition on members of >> Thread_Control_struct in rtems? As for mutex we have ticket_lock over its >> wait_queue in SMP architecture which can serve as explicit locking in >> mutex. For thread I feel data race condition may happen while setting >> *thread->current_priority. *As it is updated by thread while restoring its >> priority and while some other thread trying to promote for nested_mutex >> behavior. >> > > There is no data race condition, see _Thread_Change_priority() and > Thread_Lock_control. There is a potential problem with a deadlock at spin > lock level however, in case the application provokes a deadlock at object > level. This needs some further investigation. > > -- > 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
