Atomically set current_uthread and a 2LS sched ops
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 24 Aug 2015 14:05:22 +0000 (10:05 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 24 Aug 2015 14:18:28 +0000 (10:18 -0400)
commitcfa5f99625e14f3196df84c363c284863f559a23
tree247bf25f46656775652a378c3b877caf174e1485
parent6d7adf977ed4ec2987ec00d06e5729e3b78156ea
Atomically set current_uthread and a 2LS sched ops

When initializing a 2LS, we are setting up both a current_uthread and a
2LS sched ops.  These must be in sync any time that a 2LS op is called.

Say we change the sched ops, but not the pointer, and then we receive a
notif (or do anything that triggers a 2LS op).  Then we're using the
sched_ops sched_entry on the wrong type of uthread.  If we have the
pointer change first, then the sched_ops operation is performed on the
wrong uthread (even if it's a thread0 op, we could be have the wrong
values or something).

This change splits manage_thread0 into its two components: init and
track.  Tracking the uthread in the vcore's current_uthread is done
"atomically" with setting the sched ops, with respect to notifs and
blocking syscalls.  These are the source of unexpected scheduler ops
calls.  If there are more sources in the future, we'll have to disable
them here.
user/parlib/uthread.c