Fix kernel work counting when processes are stopped or faulted

[hudson-ayers]

Pull Request Overview

This pull request fixes a bug (identified by @bradjc ) where when a process in the Running state faults, the scheduler would hang, as the kernel work counter is not decremented appropriately. This bug existed prior to the new scheduling interface, but before manifested as the board never going to sleep, rather than hanging outright.

It also fixes a similar set of bugs where a process being Stopped or terminated when in the Running state would cause the scheduler to hang, for basically the same reason.

This PR introduces a new wrapper around Cell<State> called ProcessStateCell that takes care of incrementing and decrementing the kernel work counter based on the transitions between process states that occur. Hopefully, this should prevent similar bugs from cropping up in the future.

Testing Strategy

This pull request was tested by:

• running the crash_dummy app and verifying that other apps + the process console work after the app crashes

• faulting the whileone app while it is executing and verifying that doing so does not freeze a simultaneously running blink app

• stopping the whileone app while it is executing and verifying that doing so does not freeze a simultaneously running blink app, and then starting the app again and verifying that works correctly

all three of these cases fail on current master. I also ran 4 apps simultaneously just as a tiny stress test and that worked fine.

TODO or Help Wanted

Thoughts on naming? Should update be kept as set, so that the wrapper appears identical to a Cell?

Documentation Updated

• No updates are required.

Formatting

• Ran make prepush.

[bradjc]

Looks good. Writing an OS is hard. I should keep track of this PR for when I warn people about the dangers of duplicating state.

[ppannuto]

I think this is strictly better that what was there before. At this point, we're at a point where the only place that {incr/decr}ement_work() is valid is inside this process state cell* -- it would be nice to find a way, perhaps with visibility somehow, to more strictly enforce that.

*The other place is increment_work_external, but that's an exceptional path anyway, so building a new/different exception if needed makes sense to me

[hudson-ayers]

At this point, we're at a point where the only place that {incr/decr}ement_work() is valid is inside this process state cell* -- it would be nice to find a way, perhaps with visibility somehow, to more strictly enforce that.

*The other place is increment_work_external, but that's an exceptional path anyway, so building a new/different exception if needed makes sense to me

Unfortunately {incr/decr}ement_work() still must be called manually within process.rs whenever tasks are added/removed from the tasks queue. This could probably be resolved by forcing all modifications to the tasks queue to use the enqueue_task() / dequeue_task() functions, which is not currently the case.

[bradjc]

bors r+

[bors]

Build succeeded:

• ci-build (macos-latest)
• ci-build (ubuntu-latest)
• ci-format (macos-latest)
• ci-format (ubuntu-latest)
• ci-qemu
• ci-tests (macos-latest)
• ci-tests (ubuntu-latest)