Doubt regarding Thread_Control_struct in rtems
Saurabh Gadia
gadia at usc.edu
Thu Jul 16 21:43:04 UTC 2015
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.huber at 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.huber at embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20150716/e957e16d/attachment-0002.html>
More information about the devel
mailing list