On Fri Aug 29, 2014 at 13:46:38 -0400, Yuxin Ren wrote:
> I have some further understanding about the code.
> If thread A can go back to its home cpu(core 1), this means it is not
> running on the core 2.
> And when A release its lock, it will switch to its helper.
> During the context switch from thread A to its helper on core 2, the "
> _running_under_lock"
> of thread A should be set to false. Thus thread A is able to continue to
> run on its home cpu.
>
> I think this logic has no problem. But I observed a thread going into
> the infinite loop in Switch_lock::set_lock_owner method.
> in my test program.
> Because of inappropriate memory barrier, or anything else?
>

> On Wed, Aug 27, 2014 at 2:28 PM, Yuxin Ren <ryx@gwmail.gwu.edu> wrote:

> > I have a question about the dec_lock_cnt method in Context class under
> > multiple processor.
> > In its implementation, it checks if thread's home cpu is equal to current
> > cpu.
> > If not, it does not unset "_running_under_lock" variable, even if the
> > _lock_cnt is 0.
> > Why does it check if home cpu is equal to current cpu?

This one should work better:

Context::dec_lock_cnt()
{
  int n = _lock_cnt - 1;
  write_now(&_lock_cnt, n);
  if (EXPECT_TRUE(!n && home_cpu() == current_cpu()))
    {
      Mem::mp_wmb();
      write_now(&_running_under_lock, Mword(false));
    }
}





Adam
--
Adam                 adam@os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers