Using until() versus Wait() with multiple tasks.

[tabbycatrobots]

I have a program with 4 tasks running. There are times when task_1 is simply waiting on task_2 to complete some
sensing operations. During this time, I want task_1 to use as little CPU time as possible, so task_2 can better monitor a
sensor. If I know that task_2 won't complete the sensing operation for at least 1 second, what code in task_1 will use
less CPU time? In both choices, task_2 sets global_flag_01 = TRUE, when it finishes its sensing operations.
Choice A:
task_1 is doing its work;
it then needs to wait for task_2
Wait(990); // Task_2's sensing operation takes at least 1 second.
until(global_flag_01 == TRUE);
task_1 resumes it work

or Choice B:
task_1 is doing its work;
it then needs to wait for task_2
until(global_flag_01 == TRUE);
task_1 resumes it work

I.e., is a Wait more efficient than an until? Will the until() get executed many times during a task_2's time slice,
where with the Wait(), the scheduler will see that code, and simply not give that task any time slice for a while? Is
this a sensible question, or does the scheduler operate is some manner that doesn't fit my mental picture?

And a variation I may need in my code is, I don't know how long task_2's sensing operation will take, but I want to
minimize task_1's CPU usage while it is waiting, even if it means task_1 may not start immediately when task_2
sets the flag, so I considering Choice B above or Choice C.
Choice C:
task_1 is doing its work;
it then needs to wait for task_2
while (global_flag_01 == FALSE)
{
Wait(50);
}
task_1 resumes it work

And a related question that I wonder about, what is the standard time slice for each task?

Thanks for any ideas.
Howard

[tabbycatrobots]

Searching the forums, I found from Feb 2011, a topic "NXC: wait(1) for safe task (scheduling) control needed?".
John Hansen's comments that the task scheduler doesn't do a time slice but gives a task time for 20 operations.
This would point to the idea of using a Wait(short time) with while() or until(), rather than just an until(). I think
I'll try Choice C. If I understand correctly, the Wait(50) will immediately put task_1 at the bottom of the scheduler's
queue, and will get task_2 to a run state sooner. Any other comments / ideas are welcome, as I feel I'm at the edge
of my knowledge.

Oh, I noticed a typo in my original post:
"Will the until() get executed many times during a task_2's time slice"
should be
"Will the until() get executed many times during a task's time slice"
Thanks.
Howard

[afanofosc]

I am not entirely sure I understand your question, but if you are using a 2.0 level firmware or above (preferably the enhanced NBC/NXC firmware) then a Wait should immediately stop the current task (thread) and let the VM execute code on another task (thread). The task that called Wait will execute no more code for N milliseconds, where N is the value you passed into Wait. Your best bet might be something like this:

Code: Select all

until(gTask2SensingCompleted)
  Yield();

I.e., use a nice meaningful name for your "global flag" and don't compare a boolean value to TRUE or FALSE since it is already TRUE or FALSE. And use until just like you use while (i.e., with a body). The only difference between until and while is that until negates the while expression. So the fastest code in your task 1 would actually be

Code: Select all

while(gTask2SensingNotCompleted)
  Yield();

I.e., set your global to TRUE initially (i.e., not done yet) and then set it to FALSE when task 2 is done. That way you don't have to negate the boolean value in a while loop expression or do a comparison against FALSE. You could use Wait() and wait for longer than 1 ms but you risk waiting N ms too long in that case. Executing this sort of while loop once ever millisecond (or every other millisecond) will not take very much time away from your task 2 sensing operation.

John Hansen

[tabbycatrobots]

Thank you. I think your idea for the while / yield fits well for what I'm trying to do. I am running the NXC firmware.
I needed it for a BlueTooth feature. Regarding not using "== TRUE / FALSE", I agree, and don't use in my code, but
thought it might make my question easier to understand.