Plan for multi-tasking and IO

[bgamari]

While there already exists the skeleton of a scheduler in Zinc we need to put a bit more thought into how this will integrate with the rest of the library. In particular, the interaction between concurrency and peripheral usage needs some consideration. Most applications of concurrency in embedded systems revolve around I/O.

There are a few schools of thought on how to frame IO in the embedded world,

1. Blocking, serial: Here you require the user to pause execution to wait for the I/O to finish. This is the approach largely taken by Arduino's Wiring and it is quite limiting, especially when working with slow interfaces. Blocking can either involve sitting in a busy loop (as is often done in Wiring) or waiting for an interrupt (taking advantage of low-power wait states).
2. Non-blocking, queued: Here you allow execution to proceed, queueing the I/O for later execution is necessary. This is the approach taken by the Wiring's Serial interface for writes. Unfortunately you lose the ability to report input and/or errors back to the caller.
3. Non-blocking with callbacks: Allow execution to proceed, reporting I/O completion to the caller with a callback. This is the approach taken by the MC HCK library. Unfortunately completion passing tends to be very awkward, especially in imperative languages like C. Moreover, it's quite tricky to do correctly in Rust due to the transfers of object ownership that it requires.
4. Blocking, concurrent: Here you allow I/O to block execution of the caller but allow other tasks to run in the interim. If no other tasks are available, the core can enter a low-power state.

In the case of Zinc, option 4 stands out as it leverages the safe concurrency enabled by Rust's type system. This, however, requires that the library is built with concurrency in mind, particularly ensuring that operations requiring interaction with peripherals are thread safe.

There are a few ways to ensure this,

1. At compile time: Guarantee that no two threads have access to the same peripheral. This could be accomplished by specifying each task's peripheral requirements in the Platform Tree.
2. At run time: Wrap each peripheral in a lock

I believe that (1) is far too restrictive, requiring the user to structure their program around the needs of the library and hardware instead of the semantics that they desire.

An example of an interface in the spirit of (2) can be found here. Here the user is required to acquire a Context in order to use the peripheral. This context is responsible for grabbing a mutex and tracking transaction state.

Anyways, what do others think?

[farcaller]

Quite a bunch of RTOSes are based around microkernels, IIRC. I think this can be applied to higher level zinc as well, i.e. there is exactly one task that can talk to peripheral (as enforced by MPU in hardware and PT in software) and it communicates to user code via some thread sync primitives. Which gets us to option D.

[bgamari]

@farcaller I'm not sure it's strictly necessary to designate a single task to talk to a peripheral. It seems like this would incur context switching overhead, memory usage (due to the need for another stack), and complexity where a simple locking scheme would do.

What do you envision a dedicated task would get you above locking?

[farcaller]

Only one task can die because of badly written driver code / unexpected response from hardware / whatever.

I'm looking more into microkernels in terms of academic enthusiasm though, not actual feasibility. If I get it right, the microkernel approach adds to overall system security and stability sacrificing some resources to get there.

[bgamari]

@farcaller the microkernel architecture is interesting but I'm not sure it's worth the cost. Ultimately if something misbehaves you need to recover one way or another. The Hurd has shown that while task isolation can help make failure recovery possible, actually implementing robust recovery is still a hard problem, especially when you now have hardware in an unknown state. Especially given the resource constraints that Zinc targets I don't think it's worth the resource and complexity cost that such a scheme carries just to buy the possibility, however remote, of a somewhat graceful recovery. For the same effort you could have just implemented it correctly to begin with.

That's not to say I'm closed to the idea, just a bit skeptical.

[bharrisau]

There is an article for MirageOS looking at the two ways they achieve non-preemptive multi threading - http://openmirage.org/wiki/delimcc-vs-lwt

[farcaller]

OTOH, you can get hard real-time guarantees only on a highly-preempted architecture, right?

[bharrisau]

No, with predictable maximum execution times and a clever scheduler you can do it without preemption.

Predictable execution times is what I use too.
Knowing what they are is needed, so I normally configure them into a state machine. Using config, rather than hardcoding provides portability.

Also logging when a task goes over the time expected I use, so I know its not keeping up.