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@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@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