Like the title says, does anyone know how to multithread in pros?
Scroll down to the tasks section of the documentation:
Tasks; just like in robotc, allow you to multithread, or be it, do multiple things at once!
Robokiller, I see you have a NAR team designation. I’m assuming that you are a programer and have done some other multi threading programming before. So this is mostly directed at the rest of the programmers in the forum that went “Multi threading! I want to do that!”
Multi threading or in the RobotC terms multiple tasks are great, but you need to think through what you are doing in both the main task “main()” and your spawned tasks. The spawned tasks will continue until you kill them (or it kills the robot, which why I was amused by Robokiller’s forum name)
I’ve seen cases where the spawned task was to drive the base “forward” and the main task was working on the arm being positioned. There was some code in the main to change the direction of the robot. In practice the spawned “forward” task kept the robot moving forward, the turns in the main task were over-ridden by the “forward” task in the next time slice.
You can role play this (which is how I try to teach tasks.) Take two roboteers side by side. Have them put an arm around each other so they are “joined at the hip”. Roboteer one is to walk “forward”, the other roboteer trys to turn the joined pair. It does not work well for the “robot”
So Plan B is to have a Global Variable that both tasks (roboteers) can see. Now the role play is one task moves forward, but checks the global variable to see if they should offset the drive. The main() task updates the global variable on the direction. In the role play, the main() roboteer yells out (updates) the direction global variable. With some silliness and giggles, the two roboteers work it out and the “robot” turns.
Sometimes the spawned task wants to communicate info back to the main task. In the role play, they can both say changes out loud. This leads to confusion. In C there is a concept of Semaphore and mutex allowing two tasks to update the same variable in a co-operative fashion.
In the role play I use a ball. If you have the ball you can speak. The ball gets taken by the task, they make the change and put the ball down. You can only make a change (speak) if you take the ball.
Back in my early VRC / FRC days when we coded at a lower level, we used semaphores / mutex on a regular basis. The example in the link above is a pretty low level set of routines. But it works for other tasks, the concept is the same.
For what it’s worth when I teach the task stuff it takes an hour to get the concepts through and another hour to get the sample code to work. So if you didn’t get it all by reading the 300 words in this post, it’s OK.
TL;DR: Tasks may be the answer to your problem, but unless you think them out, they may create more “weird” problems for you to try to debug.
1 Like
Thank you EvolvingJon and Foster for breaking it down for me. And Foster, excellent eli5 for people wanting to go the “multi task” route.
–Jaxon
It should be mentioned that the Cortex is not capable of truly multithreading (it has one non-hyperthreaded CPU). It uses a time sharing concept in all implementations.
I think the term you are looking for Cody is that the cortex is not capable of parallel execution but rather it is capable of concurrent execution.
Multithreading in pros is similar to ROBOTC multithreading, so you may want to have a look at the documentation and forum posts for tasks in ROBOTC.
http://www.robotc.net/forums/viewtopic.php?t=3341
https://vexforum.com/t/robotc-programming-tips/19718/1
etc