I will refer to threads and tasks interchangeably in this post
I have ~5 threads controlling various robot devices and they all read and process input from various files saved to the micro SD. You can think of it like each thread turns some motor on, then sleeps for 20 milliseconds, then changes its velocity, then sleeps for 20 milliseconds, then stops said motor, and so on. The program works successfully to about a ~5% error but I want to know if vex::task::sleep() has the potential to sleep the thread longer than specified because that could have huge implications. As in I am too lazy to implement a gyroscope-like correction behavior for the motors and if this were to be true, I would have to put in the work. Also my competition is in a week. To summarize, does the vex::task::sleep() method ever sleep longer than specified?
I expect jpearman or others from Vex can weigh in with exact numbers, but generally at an OS level, there is some level of slop to sleep-type functions, and unless you’re running a “hard” real time operating system (RTOS), you’re going to have variability in what that timing really is. More threads will mean more overhead for the scheduler to deal with, and since I can only hazard guesses at the underlying clock rates and other things that Vex has going on below the surface, it’s not unreasonable to expect 200-500 microsecond slip past the expected time. Could be less, but with 5 threads all potentially sleeping at various points and the scheduler trying to keep everything serviced (internal watchdog, other sensors, brain refresh, etc., etc.), some slip is bound to happen.
Hopefully you’re not trying to read files from the SD from each of those threads, or I would definitely expect things to slip based on how many file read functions typically operate. Ideally you’re reading the necessary data in at the start and making it accessible to all threads in RAM.
The answer is yes, how much will depennd on the code.
When I first wrote the code, it ran out of available RAM when . However, that was partly because I was using Python. I am not sure if the running program has access to the ~24 to 32 kb of RAM that I need?
It might be helpful to the OP if you could provide “typical” bounds. If @EngineerMike 's estimates are accurate. On a sleep of 20milliseconds, a slippage of 200-500 microseconds (1-2.5% of 20millis) is one thing, if inexperienced programmers read above and start to think that sleep may slip 1-10 milliseconds (5-50%) is another.
Can you also indicate whether using vex::timer::systemHighResolution() in places where a user may decide to get a more precise time delta between loops is the best way to do so?
It depends on the platform, V5, IQ2 etc.
It’s a cooperative scheduler, if a task blocks doing something like SD card access, other tasks will be blocked also, it very much depends on the code. Everything is run from a 1mS timer tick, so 1mS jitter is quite normal. systemHighResolution() depends on the platform, V5 implements it, IQ does not (IIRC).
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.