<div dir="ltr"><div><div>For uniprocessor we have a complete ready JPF model for solving nested mutex problem.<br></div>JPF-Code: <a href="https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.1">https://github.com/saurabhgadia4/lock-model/tree/rtemsjpf-0.1</a><br><br><br></div><div>Avoid unwanted irrelevant commit messages!! The code is still in raw stage but solves all the potential cases of nested mutex problem. <br><br></div><div>For SMP we already have locking for mutex related operations:<br><br>_Thread_queue_Acquire_critical( &the_mutex->Wait_queue, lock_context );<br><br></div><div>This ticket lock is always acquired before performing any write operations in mutex_seize and mutex_surrender which are required for solving nested_mutex problem. So for SMP we just have to overcome the data race that might happen while modifying thread->real_priority.<br></div><div><br><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div>
<br><div class="gmail_quote">On Wed, Jul 15, 2015 at 4:49 PM, Saurabh Gadia <span dir="ltr"><<a href="mailto:gadia@usc.edu" target="_blank">gadia@usc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,<br></div>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 <b>thread->current_priority. </b>As it is updated by thread while restoring its priority and while some other thread trying to promote for nested_mutex behavior.<br><div><br clear="all"><div><div><div><div dir="ltr">Thanks,<div><br></div><div>Saurabh Gadia</div></div></div></div>
</div></div></div>
</blockquote></div><br></div>