[NotInControl]

Originally Posted by notmattlythgoe

Be careful though, it is not multithreaded as NotInControl has stated. It uses a scheduler to run the commands one execution at a time.

I don't want to de-rail from the OP, and get off topic with this, but I'll offer this:

I believe you are limited your definition of "multi-threading" to spawning multiple threads for the operating system to schedule which is known as "kernel-level" threads but you are forgetting about "user-level" threads.

The CommandBased Robot Structure doesn't spwan multiple operating system threads for commands, instead it opts a "user-level" thread model where the scheduler adds each new command to a linked-list and executes each Command's "run" method sequentially in a round-robin fashion. (To be complete, other operating system threads are spawned for certain items like PID controllers, compressor, some sensors etc. and are managed by the operating system, not the WPI scheduler)

The WPI scheduler apart of the CommandBased construct will automatically remove commands which have finished execution and prevent commands from being added if the requirements for the command are not met or conflict with another commands.

All of these items are done at the application-level instead of the using the operating system to manage threads which can be classified as "user-level" threads.

In both models, time-division multiplexing is being done to share the resources of the single processor on board. Which is the basic definition of concurrency.

If there was only a single thread and the program only ran sequentially without time sharing then you would never need a scheduler.

So whether you want to call it multi-threading or not is your opinion, to the end user concurrency on a single processor is being done, I didn't state all of this before because I didn't want to muddy/confuse my original post.

Hope this helps,
Kevin