[Click] [PATCH 2/2] Task: Kill process_pending dead lock

[Eddie Kohler]

Joonwoo,

 > I took look into this lock up issue and I think I found something.
 >
 > RoutherThread::driver() calls run_tasks() with locked tasks.
 > But after calling run_tasks(), current processor can be changed since
 > schedule() might be called (eg. ScheduleLinux element)
 > So I think that's problem.  How do you think?

I totally agree that this could be a problem.

It looks like EXCLUSIVE handlers never really worked before. :(

So my current analysis is this.  It is not appropriate for a thread to 
call blocking functions and/or schedule() when that thread has prevented 
preemption via get_cpu().  My prior patches prevented preemption.

The solution is to separate "locking the task list" from "blocking task 
execution."  Clickfs, when executing an exclusive handler, "blocks task 
execution."  A thread that wants to examine the task list "locks" the list.

This commit:
http://www.read.cs.ucla.edu/gitweb?p=click;a=commit;h=ede0c6b0a1cface05e8d8e2e3496ee7fcd5ee143
introduces separate APIs for locking the list and blocking task 
execution.  Exclusive handlers block task execution, but do not lock the 
task list.  I believe that task execution, in this patch, does not 
prevent preemption.  I believe the locking works out too.  User-level 
multithreading tests appear OK.

Any willing stresstesters?  Pretty please? :)

Eddie