Question about dec_lock_cnt method in Context class

[Yuxin Ren]

There are three places where "_running_under_lock" is set to true;

First one is just in the above loop. So this code will run only after it
goes into the loop.
This does not help explain why the code can go into the loop.

The second is in Context::running_on_different_cpu() method in context.cpp
file.
if (EXPECT_FALSE(lock_cnt())
    && EXPECT_FALSE(!mp_cas(&_running_under_lock, Mword(false),
Mword(true))))
return true;
But this only happens when lock_cnt is non-zero.

The third one is in Context::need_help method in context.cpp file.
The method is called only when a thread tries to help the lock holder.
I think this implies that the lock holder holds a lock and as a result, its
lock_cnt is not 0.

Just from those code, I think it is impossible for a thread that its
"_running_under_lock" is true while its lock_cnt is 0.
However now that the code is here, I want to know why the author add the
"extra" check here?
The author should have some reason to do so, right?

Thanks a lot!!
Best,
Yuxin


On Tue, Sep 9, 2014 at 5:03 PM, Adam Lackorzynski <adam at os.inf.tu-dresden.de
> wrote:

> On Mon Sep 08, 2014 at 11:54:32 -0400, Yuxin Ren wrote:
> > Unfortunately this modification does not help.
> > I have a question about the switch_lock code.
> >
> > PRIVATE inline
> > bool NO_INSTRUMENT
> > Switch_lock::set_lock_owner(Context *o)
> > {
> >   bool have_no_locks = o->_lock_cnt < 1;
> >
> >   if (have_no_locks)
> >     {
> >       assert_kdb (current_cpu() == o->home_cpu());
> >       for (;;)
> >         {
> >           if (EXPECT_FALSE(access_once(&o->_running_under_lock)))
> >             continue;
> >           if (EXPECT_TRUE(mp_cas(&o->_running_under_lock, Mword(false),
> > Mword(true))))
> >             break;
> >         }
> >     }
> >     ...
> > }
> >
> > In which case, the variable "_running_under_lock"  is set to true but the
> > lock_cnt is 0?
> > Now in my test, the kernel goes into this dead loop.
>
> Do you know when it was set to true? Maybe that would help finding out
> why it is stuck there?
>
>
>
> 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/20140909/0e970266/attachment.htm>