Question about dec_lock_cnt method in Context class

[Yuxin Ren]

Thanks a lot!
I will try it.
But could you explain to me why this is better?
I am really curious about how to implement and debug such staff.

Best
Yuxin


On Mon, Sep 1, 2014 at 5:58 AM, Adam Lackorzynski <adam at os.inf.tu-dresden.de
> wrote:

> 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 at 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 at os.inf.tu-dresden.de
>   Lackorzynski         http://os.inf.tu-dresden.de/~adam/
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20140901/7b6f58f9/attachment.html>