heliosproj / HeliOS

A community delivered, open source embedded operating system project.
http://www.heliosproj.org
GNU General Public License v2.0
352 stars 42 forks source link

Waiting Tasks are limited < WAITINGTASKSIZE #12

Closed kwrtz closed 2 years ago

kwrtz commented 3 years ago

I think that could be a problem:

If you have for example 15 timer tasks.

Ten of them runs every 10ms for example and five of them runs every 200ms. That five are at the end of the task list. It could be that this five tasks will never run, because the scheduler always make a TaskListRewind(), start from the front of the list and limit the waitingTask[waiting] to 8. Because of that limit and the reset of the list it could be, that the scheduler will never reach the 200ms tasks because the 10ms task want alway to run.

MannyPeterson commented 3 years ago

@kwrtz thank you for pointing out the potential condition that could arise from having > 8 tasks in a waiting state. Once I get through some other items I will look into this further. Thank you.

JakubRakus commented 3 years ago

Confirmed. Creating more than WAITINGTASK_SIZE timer tasks causes to run only 8 first tasks. Attached simple app which shows that behavior (it's modified linux example). If I change #define WAITINGTASK_SIZE in HeliOS.h to accommodate greater number of tasks it runs smoothly and all tasks are executed in predictable order.

main.c.txt

MannyPeterson commented 3 years ago

@JakubRakus thank you for confirming. My plan is to address this in a future release by using a private pointer to the current list node. Right now that pointer is shared. By using a private pointer for the scheduler I can eliminate the task array of waiting tasks.

JakubRakus commented 3 years ago

@MannyPeterson Yeah, I saw discusion in #7 and think that list of pointers is the best solution which should resolve this issue (and probably others which comes out in future). I also thought about initializing an array on the fly with some memset if You'd like to stay with integer as task's id.

MannyPeterson commented 2 years ago

@JakubRakus see #7 but this is no longer an issue as the scheduler has private list pointers.