Enforce Task Order, How Exactly Does It Work??
Rich D
This is what is listed in the user guide.
Same-Profile Tasks
Tasks launched by the same profile by default always execute in the order in which they are launched. Other tasks from the same profile remain completely inactive until any previous task from the same profile is complete. The main purpose of this rule is to correctly handle rapid changes in a profile's activation state.
This behaviour can be disabled by deselecting Enforce Task Order in the Profile Properties dialog.
Example
This example demonstrates the effect of Enforce Task Order and shows also how sub-tasks launched by Perform Task are handled.
Profile: Example Enter Task: Enter1 Perform Task, Enter2 Exit Task: Exit1 Perform Task, Exit2
With Enforce Task Order:
Enter1 and Enter2 are both guaranteed to finish before either of Exit1 or Exit2. Whether Enter1 or Enter2 finishes first depends on their relative priority. Same for Exit1 and Exit2. All 4 tasks compete based on priority against tasks from other profiles. Exit tasks have a higher base priority so will finish before Enter tasks.
Without Enforce Task Order:
If the profile goes active and inactive quickly,Enter1,Enter2,Exit1 and Exit2 will all compete purely on priority. Since Exit tasks have higher base priority,Exit1 and Exit2 will probably finish first.
And this is what the info help is on the setting itself.
Ensure tasks started from this profile activation or deactivation remain queued until previous tasks from this profile are complete.
So, after reading all that It was aways my assumption that this setting would ensure that tasks from the same profile would be "started" in the proper order. For example no matter how many times the profile activates and deactivates quickly the enter and exit task would be queued to start like enter: exit: enter: exit: enter: exit. etc....
As with most things tasker it is not that simple... I have recently discovered that tasker does not enforce the "starting" of the task but it enforces when the actions will run. Which is not the same thing. If you view it in the run log you will see that every activation of the profile the enter task will be started and for every deactivation the exit task will start. But they will not necessarily run.
So because the tasks are actually started they are subject to being aborted or replaced ( depending on the task collision settings) when another iteration of the same task is started due to quick context toggling.
This needs to be taken into account when trying to figure out quick toggling problems. Given there are 3 different task collision settings and depending on if either or both tasks have wait actions, there are far to many possibilities to list but here is just one for a example.
Assuming the exit task has a 30 sec wait and collision set to 'abort exsiting' with 'enforce task order' selected.
Enter task has no wait : collision set to 'abort new'
1. Profile goes active
Enter task runs and exits
2. Profile goes inactive
Exit task starts and starts the wait
3. Profile goes active within 5 seconds
Enter task starts but does not run
4. Profile goes inactive
Second iteration of exit collides and replaces the existing exit task and starts and starts the wait action
5. Now that the first iteration of exit task has been aborted this allows the enter task to run. Enter task runs and exits.
// this is the second time the enter task has run without letting the exit task run//
6. Profile goes active again within a few seconds
Enter task starts but does not run
7. After 30 seconds
exit task finishes running
8. Once exit task finishes
Enter task runs.
So in the end the enter task ran twice then the exit task ran then the enter task ran (enter/enter/exit/enter). And the profile is now active. So all is well except if you were counting on the tasks to alternate in order.
No matter how I set the collision properties the tasks would not alternate in order.
I believe it can be done by adding a "Stop : If %TRUN matches *,name of exit task,* at the beginning of the enter task.
This is just one example to show how the order of task execution can vary..
Hope this helps and if someone sees any misinformation here please post for others...
Thanks, Rich..
Bob Hansen
Brandon Horwath
+1
Rich D
Thanks for taking the time to clearly document your investigation into this. Very useful information!
> Awesome info Rich
>
> +1
>
No problem... hope it helps someone.... :)
I forgot to mention that it was Matt R that pointed this out to me in a recent post, apparently some users actually can read between the lines of the users guide. If you look closely pent does explain this here..
Ensure tasks started from. """this""" profile activation or deactivation remain queued until previous tasks from this profile are complete.
Well I guess it is a explanation for some Anyway, A hidden clue for others... :)