Multithreading on Java

[1757]

I understand that there's a Task class in C++, but how do I multithread in Java? I can't find any Java counterpart to the C++ class. Thank you

[BornaE]

http://docs.oracle.com/javase/tutori...runthread.html

[1757]

okay thanks, I didn't think to try that because it's not native to the cRIO

[jwakeman]

The Command Based programming model available through the WPILib is a good way to achieve concurrency in your software.

http://wpilib.screenstepslive.com/s/...ed-programming

[Ether]

Originally Posted by jwakeman

The Command Based programming model available through the WPILib is a good way to achieve concurrency in your software.

http://wpilib.screenstepslive.com/s/...ed-programming

Quoting from the linked document:

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

... so how does that work, exactly?

[fovea1959]

the Scheduler when using command based maintains it's own list of active commands, and (when a DS packet arrives) calls their execute() and isFinished() methods for every command on the list (sequentially).

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

[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.

[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.