Thanks, I won’t add it then.
I see that there is something called multitasking as well.
I looked at the example, and it looks exactly the same as multithreading.
What is the difference between it and multithreading?
Maybe there is a typo in comment brief - where it is says “Permits the thread to execute from the thread handle…”
I think the comment needs to state “Simulates the thread to exit from the thread handle…”
== noop
No difference. For various legacy reasons VEXcode provides both names with identical capabilities.
5 Likes
^
ROBOTC was the VEX-default language before VEXcode. Initially, they used the V4/cortex system, and when teams switched to V5 I believe jpearman wanted a smooth transition for teams who previously used ROBOTC. That is why in my PID tutorial I use task instead of thread, simply because I was used to the ROBOTC infastructure initially. But you can use them pretty interchangably. The only difference really is the name.
3 Likes
Yes, here’s a little background.
The genesis of the scheduler that VEXcode uses was towards the end of 2015. At that time we thought that RobotC may still run on the V5, I actually did a port of the IQ version of RobotC and had that running. You can see the tiny IQ screen (128x64 pixels) in the bottom corner of this picture.
However, it was decided that we needed to move to a cross platform solution for programming and that the RobotC compiler and VM had reached the end of their useful life, there was just too much technical debt to try and rewrite everything, but that’s a story for another day. The RobotC scheduler had many student friendly features, that is, it was very tolerant of misuse, doing things like treating tasks as functions and calling them over and over. Most conventional embedded schedulers (things like FreeRTOS) are not nearly so tolerant of abuse and can often be difficult to debug. A scheduler was created that was influenced by RobotC but internally was quite different, this is embedded into vexos and was used by Vex Coding Studio and subsequently VEXcode.
The original C++ class we offered was vex::task, this used terminology familiar to RobotC users and is a lightweight class that simply wraps many underlying C API calls. The reason why creating a vex::task with the same callback function just restarts that function is because that’s how RobotC worked. You will see many other class member functions that mimic RobotC, stop(), suspend(), resume() and priority().
But then someone suggested we should be using something closer to std::thread, so we created vex::thread as another lightweight class that wrapped the same underlying C API, oh what fun. We tried to match it’s class member functions to those in std::thread but some just don’t directly correlate. std::thread is also missing some key functionality we wanted. For example, there’s no way to set a thread’s priority from the standard library and no way for one thread to stop another.
So we have two classes that do more or less the same thing and call the same APIs in vexos but have different names.
11 Likes
This is the main reason why I want to use threads to be honest. Autonomous is so much easier to code in certain places if you can, for instance, start the ring intake and move an arm up and down while the robot in moving forwards to get a neutral goal.
Understatement of the day…
7 Likes