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.

[Ether]

Thank you everyone for the responses. I've been carefully reviewing them all and I think I now have a reasonably coherent idea of how command-based works.

There are however a few seeming inconsistencies (or perhaps ambiguities) that I'd like to resolve. Here are two:

Firstly, it is necessary but not sufficient that each individual command in the scheduler's queue complete within 20ms. Rather, the sum total of the individual execution times must be less than 20ms. Correct?

Secondly, the scheduler maintains not only a queue of all the commands to be run, but also the state of each command... and only the method corresponding to each command's state is executed. Correct? (Compare post 15 to post 17 for example of apparent inconsistency).

[Joe Ross]

Originally Posted by Ether

Firstly, it is necessary but not sufficient that each individual command in the scheduler's queue complete within 20ms. Rather, the sum total of the individual execution times must be less than 20ms. Correct?

Correct

Originally Posted by Ether

Secondly, the scheduler maintains not only a queue of all the commands to be run, but also the state of each command... and only the method corresponding to each command's state is executed. Correct? (Compare post 15 to post 17 for example of apparent inconsistency).

This gets a little bit tricky because of the abstraction. The users creates a "Command" that extends the Command class, which is an abtract class. The Command class implements the state machine, but not the initialize, execute, isFinished, end, and interrupted methods. The user's "Command" implements the initialize, execute, isFinished, end, and interrupted methods. It would be possible for the user to override other methods of the state machine, but I have not seen anyone do it. The scheduler calls the run method of the Command class, which increments through the state machine in the way that notmattlythgoe described. To the casual user, it would appear that the scheduler is doing it because the user doesn't implement any code for the state machine.

[notmattlythgoe]

Originally Posted by Ether

Thank you everyone for the responses. I've been carefully reviewing them all and I think I now have a reasonably coherent idea of how command-based works.

There are however a few seeming inconsistencies (or perhaps ambiguities) that I'd like to resolve. Here are two:

Firstly, it is necessary but not sufficient that each individual command in the scheduler's queue complete within 20ms. Rather, the sum total of the individual execution times must be less than 20ms. Correct?

Secondly, the scheduler maintains not only a queue of all the commands to be run, but also the state of each command... and only the method corresponding to each command's state is executed. Correct? (Compare post 15 to post 17 for example of apparent inconsistency).

Yes to your first point. The goal would be that the sum total of all of the commands be less than the 20ms refresh rate. In general, commands should be pretty simple in their implementation to help with this.

The second point is also correct. The only real state that the scheduler needs to keep track of is which commands are running for their first time. The only thing I'd like to clarify further is that once a command is finished it is removed from the scheduler.