View Single Post
  #8   Spotlight this post!  
Unread 08-01-2014, 06:00
notmattlythgoe's Avatar
notmattlythgoe notmattlythgoe is offline
Flywheel Police
AKA: Matthew Lythgoe
FRC #2363 (Triple Helix)
Team Role: Mentor
 
Join Date: Feb 2010
Rookie Year: 2009
Location: Newport News, VA
Posts: 1,725
notmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond reputenotmattlythgoe has a reputation beyond repute
Re: How to make timed sequences in java?

Quote:
Originally Posted by NotInControl View Post
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
You are right, it is user-threaded. I made the point because the user threads will not force a thread out that is taking too long to execute. So if you create a command that will take a long time to finish one execution it will lock all of the other commands that are waiting on the scheduler to tell them to run. Just something to watch out for.

Last edited by notmattlythgoe : 08-01-2014 at 07:46.