Doubt regarding Thread_Control_struct in rtems

[Saurabh Gadia]

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>