Multithreading on Java

[Ether]

Originally Posted by fovea1959

No preemptive scheduling here, everyone's execute() and isFinished() has to play nice....

So it's still up to the programmer to use something like a state machine or perhaps yield() statements to achieve this? Or am I misunderstanding this?

[notmattlythgoe]

Originally Posted by Ether

So it's still up to the programmer to use something like a state machine or perhaps yield() statements to achieve this? Or am I misunderstanding this?

Each command needs to finish its execute command quickly, any waits or long executions will cause everything else to come to a halt until it is finished.

[Ether]

Originally Posted by notmattlythgoe

Each command needs to finish its execute command quickly, any waits or long executions will cause everything else to come to a halt until it is finished.

So how does the command based programming model help the novice programmer achieve concurrency, like for example when they want to wait for 3 seconds after performing one action before performing the next action, without stalling their processing of the 20ms DS packets ?

Please note: this is not veiled criticism of the command based model; I'm just trying to untangle things.

[notmattlythgoe]

Originally Posted by Ether

So how does the command based programming model help the novice programmer achieve concurrency, like for example when they want to wait for 3 seconds after performing one action before performing the next action, without stalling their processing of the 20ms DS packets ?

Please note: this is not veiled criticism of the command based model; I'm just trying to untangle things.

You can create something called a CommandGroup which will run one command after another in a series (much like a series in labview), the Command Based API has a WaitCommand provided which will act as a wait period in seconds. It can also be done in a normal command by noting the initial time the command was started and basing actions off of the time since the start time.

[Ether]

Originally Posted by notmattlythgoe

You can create something called a CommandGroup which will run one command after another in a series (much like a series in labview), the Command Based API has a WaitCommand provided which will act as a wait period in seconds.

The way you worded that doesn't clearly answer my question.

Let me try re-wording it:

You can create something called a CommandGroup which contains a sequence of commands, intended to be executed one after another. The scheduler will queue the first of those commands, then queue the next command when the previous one has completed, and so on until all the commands in the group have been so queued (and therefore run in sequence). The Command Based API has a WaitCommand. The WaitCommand is not queued. Rather, when the scheduler encounters a WaitCommand in a CommandGroup, the scheduler does not queue the command following the WaitCommand until the specified time has expired.

I have no idea if the above description is an accurate account of what the Command Based implementation actually does, but is that what you meant?

It can also be done in a normal command by noting the initial time the command was started and basing actions off of the time since the start time.

That's a sort of state machine, with time being the state variable.

[BigJ]

Commands can be running "simultaneously" as long as they don't require writing data to the same Subsystems. CommandGroups are used mainly for automation (ex. I might have a ShootAndReload command group that releases my winch, then proceeds to roll it back up again immediately by calling the different Commands in a certain configuration). You can add Commands to a CommandGroup to run in sequence or parallel.

[Ether]

Originally Posted by BigJ

Commands can be running "simultaneously" as long as they don't require writing data to the same Subsystems.

That statement taken at face value would seem to allow the following:

Command A requires only Subsystem B and takes 1ms to complete.

Command X requires only Subsystem Y and takes 3 seconds to complete

Since Command A and Command X don't require writing data to the same Subsystems, they can be running simultaneously

My question is, how does the CommandBased model implement this, if not by preemptive time-slicing.

Posts 6 and 8, and post 10 if I interpreted it correctly, would answer that question.

[BigJ]

They aren't actually running simultaneously. I'm not sure if I'm interpreting "preemptive time slicing" correctly, but any Command-Based program could be written in the IterativeRobot style with a large number of if statements . They're all running on one thread as I understand it, and I am not sure you have any guarantee to the order they run in. That is why Commands can declare that they require exclusive access to a Subsystem to tell other Commands that they will be writing data to it.

Both commands will run the execute() method in their class each robot loop (usually 20ms) until their isFinished() check (also run each loop) returns true. The Scheduler takes care of all the behind-the-scenes work of maintaining command life-cycles.

[Ether]

Originally Posted by BigJ

...I'm not sure if I'm interpreting "preemptive time slicing" correctly...

I appreciate your efforts at explanation, but I think the answer I am seeking lies in posts 6, 8, and 11. I'm hoping notmattlythgoe can provide an answer to post 11.

[edit] Just saw Joe's post and am studying it...

[Jared]

Originally Posted by Ether

That statement taken at face value would seem to allow the following:

Command A requires only Subsystem B and takes 1ms to complete.

Command X requires only Subsystem Y and takes 3 seconds to complete

Since Command A and Command X don't require writing data to the same Subsystems, they can be running simultaneously

My question is, how does the CommandBased model implement this, if not by preemptive time-slicing.

Posts 6 and 8, and post 10 if I interpreted it correctly, would answer that question.

The commandbased model waits for a command's initialize, execute, or finish method to finish completely before moving on to the next method scheduled. There's no preemptive time slicing or threading going on. If your code for any command takes >20ms to execute, the whole thing falls to pieces.

The provided PID controller does start it's own thread to do PID math, and can update the motor speed from this thread too.

[Joe Ross]

Originally Posted by Ether

That's a sort of state machine, with time being the state variable.

A command is a state machine. The scheduler handles transitioning between states. The states are listed below:

initialize
execute
end
interrupted

The user provides the code that goes in those methods. There is a fifth method (isFinished()) that allows the scheduler to know when to transition from execute to end.

The normal flow is from initialize to execute to end. The scheduler handles interrupting, if a new command is scheduled that requires the same subsystem.

A CommandGroup allows multiple commands to be scheduled sequentially or in parallel (being in parallel requires that they don't require the same subsystem).

The only times we have had to add an explicit state machine inside a command, is when there is decision logic that needs to go backwards in states. In our case, that's been relatively rare.

The scheduler is entirely cooperative. It depends on the commands methods executing quickly and returning. If the user puts an explicit Timer.wait() in a command, it breaks the execution model. The user can either use a WaitCommand, or check a timer in the isFinished method, or implement their own state machine. We've done all 3.

[notmattlythgoe]

Originally Posted by Ether

The way you worded that doesn't clearly answer my question.

Let me try re-wording it:

You can create something called a CommandGroup which contains a sequence of commands, intended to be executed one after another. The scheduler will queue the first of those commands, then queue the next command when the previous one has completed, and so on until all the commands in the group have been so queued (and therefore run in sequence). The Command Based API has a WaitCommand. The WaitCommand is not queued. Rather, when the scheduler encounters a WaitCommand in a CommandGroup, the scheduler does not queue the command following the WaitCommand until the specified time has expired.

I have no idea if the above description is an accurate account of what the Command Based implementation actually does, but is that what you meant?




That's a sort of state machine, with time being the state variable.

I'm sorry, I'll try to be more descriptive since I don't think I provided enough information. Btw, I hope the presentation I sent you earlier in the build season was helpful.

The scheduler keeps a list of currently running commands on the system. The execution happens as follows:

1. Gets next command in the list
2. If this is the first time this command is going to run, execute the commands initialize().
3. Execute the command's execute().
4. Execute the command's isFinished(), if the method returns true execute the commands end(), otherwise add the command back onto the list at the end.
5. Repeat steps 1-4.

For the system to work the commands methods need to execute quickly. This means not putting in any waits in the code or the scheduler will not not move onto the next command.

Now, onto the WaitCommand I was talking about before. The CommandGroup allows you to add commands to run in sequence, below is an example that will deploy and arm, wait 5 seconds, then retract the arm.

addSequential(new DeployArmCommand());
addSequential(new WaitCommand(5));
addSequential(new RetractArmCommand());

How does this work? Good question. The first command DeployArmCommand is added to the scheduler's list for execution. Since the Scheduler is constantly running this will cause the command to start executing in the normal sequence along with any other commands currently running. Once the DeployArmCommand returns a true value from its isFinished() the next command, which is the WaitCommand, will be added to the Scheduler's list. I'm assuming the wait command is set up as a sort of state machine as discussed earlier which will return a true value from its isFinished() once the specified time in seconds has elapsed.

I hope this makes it clearer than I described earlier. If you need any more clarification on anything let me know.

[jwakeman]

Originally Posted by Ether

Notice that the apparent concurrent execution is done without the use of threads or tasks

I would say that using tasks or threads also only give the appearance of concurrent execution. There is only one cpu that can only execute one instruction at a time so the operating system is giving the appearance of concurrence by executing one task for a short time then saving that task off and executing a second taks for a short time and then switching back (context switching). If both of those tasks are "busy" (i.e. doing lots of computations) then switching back forth between the two will only make them take twice as long but get done at the same time (assuming they are doing the same exact job for illustration). If one task works all the time and a second task mostly sleeps and works sporadicly then multiple tasks might make more sense.

Of course if you have multiple execution cores and are actually assigning tasks to run on those different cores that is a different story.

If you are using tasks then you can block (sleep/wait) in those tasks and the operating system will take care of running other tasks that are ready to work.

The Command Based model provided by WPILib is really simulating the behavior of the operating system's scheduler. It does so by using a single task to call the execute() method of any command that is scheduled to run. Those execute() methods must be non-blocking (execute quickly) so that the scheduler can all the other commands that are waiting to run in that cycle.


Example: You want to run a motor until a limit switch is pressed. The execute() method of the Command should set the motor output to some speed then return immediately. The isFinished() method of the Command should return true when the limit switch is pressed. You may also want to drive the robot during the time this first operation is occuring. In the execute() your drive Command (which requires a different subsystem) should read the joystick input and update the drive motors set points and then return immediately. The isFinished() method in the drive command should always return false. The scheduler will run the execute() on both commands every 20 ms until the first command finishes. Then will continue to run the drive command.