On 24/07/15 04:41, Saurabh Gadia wrote:
#if defined(RTEMS_SMP)
RTEMS_INLINE_ROUTINE void _Thread_Lock_restore_default(
Thread_Control *the_thread
)
{
_Atomic_Fence( ATOMIC_ORDER_RELEASE );
_Thread_Lock_set_unprotected( the_thread, &the_thread->Lock.Default );
}
what does this atomic fen
Since the strict order mutexes are broken by design I didn't bother to
make them available on SMP configurations. So, basically everything
under #ifdef __RTEMS_STRICT_ORDER_MUTEX__ will likely not work on SMP in
many ways.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82
#if defined(RTEMS_SMP)
RTEMS_INLINE_ROUTINE void _Thread_Lock_restore_default(
Thread_Control *the_thread
)
{
_Atomic_Fence( ATOMIC_ORDER_RELEASE );
_Thread_Lock_set_unprotected( the_thread, &the_thread->Lock.Default );
}
what does this atomic fence does when we set Lock.current=Default in
As per thread initialization in threadinitialize.c we should acquire
default lock i.e the_thread->Lock.Default. Am I right?
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 6:58 PM, Saurabh Gadia wrote:
> basically every time we try to acquire mutex there should be lock
> acquisition related exec
basically every time we try to acquire mutex there should be lock
acquisition related executing thread.
Thanks,
Saurabh Gadia
On Thu, Jul 23, 2015 at 6:47 PM, Saurabh Gadia wrote:
> hi,
>
>
> Scenario:
> thread t1: current_priority = 5, mutex acquired = m1, m2
> thread t2: current_priority = 3
hi,
Scenario:
thread t1: current_priority = 5, mutex acquired = m1, m2
thread t2: current_priority = 3, mutex_acquired = None
flow: thread t1 tries to acquire mutex m3 and thread t2 tries to acquire
mutex m1 which is already acquired by thread t1 simultaneously on SMP.
Action:
thred t1 finds th
