Priorities not working?

[George-JL]

I am trying to test the ArduinoProcessScheduler and it seems to me that process priorities are not working properly. The TestSchedule.ino.txt code is expected to run three identical processes with the same period of one second and three different priorities.
The output
Process: 1 at 1000.492 ms runNo=1 Priority=0
Process: 2 at 1001.564 ms runNo=1 Priority=1
Process: 3 at 1002.844 ms runNo=1 Priority=2
Process: 1 at 2000.932 ms runNo=2 Priority=0
Process: 2 at 2002.004 ms runNo=2 Priority=1
Process: 3 at 2003.284 ms runNo=2 Priority=2
Process: 2 at 3000.352 ms runNo=3 Priority=1
Process: 3 at 3001.420 ms runNo=3 Priority=2
Process: 1 at 3002.708 ms runNo=3 Priority=0
Process: 3 at 4000.800 ms runNo=4 Priority=2
Process: 1 at 4001.864 ms runNo=4 Priority=0
Process: 2 at 4003.152 ms runNo=4 Priority=1
Process: 1 at 5000.216 ms runNo=5 Priority=0
Process: 2 at 5001.348 ms runNo=5 Priority=1
Process: 3 at 5002.628 ms runNo=5 Priority=2
is rather unexpected. I believe the processes should always run in the same order.

Where is the problem?
What am I doing wrong?
Is it an interference with the Serial output delays?
Or did I miss something with the non-preemptive multitasking?

Thanks for response.

[wizard97]

This was actually intentional to prevent resource starvation for new users to the library. If somewhen made a high priority service constantly process, it will prevent all the lower ones from ever running.

In the current 1.0 branch, priorities only determine how often the process is given an opportunity to run, it gives no guarantee about the order.

However, I'm starting to change my mind about this decision. In fact, I just made a strict-priorities branch, that should implement what you are asking. It is completely untested, as I am away from home. Please test it and let me know.

[George-JL]

@wizard97:
I made some basic tests of your strict-priorities branch. Unfortunately, it didn't change anything in Scheduler behaviour, except it ignores iterations argument.
I made another experiment (with the master 1.0 branch): When I added resetTimeStamps() call at the end of the service() method, the Scheduler started to keep the expected order.
I also suspect a bug:

  myProc1.add(true);    //  myProc1(sched, HIGH_PRIORITY,   1000, 10);
  myProc2.add(true);    //  myProc2(sched, MEDIUM_PRIORITY, 1000, 10);
  myProc3.add(true);    //  myProc3(sched, LOW_PRIORITY,    1000, 10);

which works fine.
When I comment out the MEDIUM_PRIORITY process, the Scheduler produces chaotic order of processes.

[wizard97]

Thanks for your testing!

I think I found the issues in the strict-priorities branch that you were experiencing, it was basically just a couple of lines in the wrong place.

If you don't mind could you give it another shot and let me know?

[wizard97]

Any luck? I am interested in merging this into the dev branch

[George-JL]

Aaron, I am sorry, but I am out for a long term travel having limited access to Internet and no access to my development/testing equipment. I'll be back at mid of August. George

[wizard97]

Thanks, just wanted to check in. It would be awesome if you could test this on the same program when you get back so I can close this issue.

Aaron

[George-JL]

Aaron,

back at my test site. The strict-priorities branch seems to work properly. Its only issue, I have detected, is that the Process parameter iterations is still ignored and the processes run forever.

George

[George-JL]

Sorry, I had a typo in my test prog. iterations also work fine!

[wizard97]

Awesome, glad to here! Thanks for the testing. Would you be willing to include your test program as an example? Might be helpful to others to understand how everything works.

[George-JL]

Here is my test program ProcessPrioritiesTest.ino.txt
I still discovered a strange behavior: When I comment out the return statement on line 65, I get a garbage.

[George-JL]

This tester gives better output: ProcessPrioritiesTest.ino.txt

[wizard97]

So if line 69 is commented out, you get garbage?

[George-JL]

Yes.
If I try to "Serial.print()" from onEnable() callback, the whole scheduling procedure breaks down. I suspect some timing interaction with the serial line.
Tested on Adruino Nano v3 clone with CH340 serial chip.