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 na
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, Seba
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
For uniprocessor we have a complete ready JPF model for solving nested
mutex problem.
JPF-Code: https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.1
Avoid unwanted irrelevant commit messages!! The code is still in raw stage
but solves all the potential cases of nested mutex problem.
For
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
