Running multiple tasks

I have a questions about running multiple Tasks at the same time. If I have multiple Tasks monitoring for an event, such as a button press, will all Tasks “see” the event and execute the desired steps? Or will only one Task 'grab" the event and the other Tasks not see it?

Forgot to mention I was programming in RobotC.

It depends on how you are monitoring for the button press, but likely yes. It would help if you posted the code.

@Aeden_6007 is right. If you’re doing a quick loop inside the tasks you’re OK. But if one task takes over without any delays for a while, especially if it is a high-priority task (Can you set priorities in RobotC?), you might starve the other task so it wouldn’t see the button press. But I would think that would be unlikely most of the time.

The code is basically this…

Task1()
while(true){
if buttonA
do this;
else
do this;
}
wait1ms(20);
}
}

Task2()
while(true){
if buttonA
do this;
else
do this;
}
wait1ms(20);
}
}

Both tasks are started in the Main. I’d like to have both tasks “see” the button press. I guess if they don’t I could always set a flag in Main on button press and then have the tasks monitor the flag instead of the button.

*ugh, sorry about the formatting

Both tasks will see the button press. When you test a button you are testing the current state of the button, it’s not an event that once read is negated.

yes, either when the task is created or later using a specific task priority function.

For those wanting an advanced understanding of how ROBOTC tasks work inside the VM, see this thread.
https://vexforum.com/t/discussion-on-using-tasks-in-robotc/33025/1

Correct me if I’m wrong, but aren’t those two statements slightly contradictory, though likely negligibly in this case? We’re not really talking about two parallel evaluations, are we? Sure, I can build a circuit where two different transistors trigger off the same capacitor’s voltage level, for instance. But we don’t have two parallel processors here. We’re threading multiple tasks through the same processor, right? So the tasks trade off usage, while the processor is only truly processing one command at a time. That means, since testing the button is testing the current state and that the testing is done at two different times, that the two values read are not necessarily the same thing. So both tasks will see the button press if it doesn’t disappear before they’ve both checked it, right? So both tasks will see the button press if neither of them is being starved to the point where the button press might have changed, right? That was what I was wondering about with the specific code and why I made my comments about the unlikely possibility of starving one of them, knowing at least three tasks are running (maybe more?) and not knowing the code (no delays?). That’s why I didn’t want to guarantee both tasks would see the button press without knowing little more about “do this;” and if there are more than three tasks running.

There are boundary cases as you describe, I was just trying to keep it simple. We do know a few things about controller buttons and the way tasks operate.

  1. controller values only change approximately every 20mS (slightly less but that’s not important).
  2. User press of a button will often be much longer than 20mS, so the state of a button will probably be maintained for 40mS or greater.
  3. Any task running with the general format of “test button, wait 20mS” is unlikely to miss the button press. You have to try pretty hard to starve a task from running for that long. Even without any wait statements we only allow a task to run for at most 1000/(number of tasks) opcodes, that’s a variable amount of time but usually only a few mS.

ROBOTC doesn’t really have events. A button press event would want to store the fact that the button state had changed and save that for processing at some point in the future. ROBOTC does have semaphores and it would be possible to have a single task reading the button state and signaling other threads via the use of semaphores, but that’s overkill for this situation.