This test is a little subtle: it wants to spawn three threads to run
and be switched out by a timeslice interrupt. And it wants to consume
half a time slice itself before it starts running. And, because
timeslicing runs out of the same tick framework in the timer driver,
it needs to align to the start of a tick before the process starts.
And further: it does its own time math not in ticks but in timer
cycles, so it's quite sensitive to slop.
But it's "synchronize to tick boundary" code was actually
synchronizing to a CYCLE boundary, which is just wrong. And it was
doing this in the wrong order. It was resetting the timeslice first
and then synchronizing to a tick by spinning, which means that the
test was always going to begin as much as a tick late. Do the tick
synchronization (via a sleep) first.
Finally, the manager thread that was spawning the new threads lives at
the same priority as the highest priority child threads, which means
it can potentitially wake up on the semaphores that they are giving in
the middle of the test and consume CPU unexpectedly. Make sure it's
sleeping for the duration.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
0875740a34