MQX Task Scheduling Question

[pmt]

I have a quesion about MQX's task scheduling policy.  For the purposes of this question assume round robin is disabled.  Say I have three tasks:

TASK1_PRI(5) // highest priority

TASK2_PRI(6)  

TASK3_PRI(6) 

Task2 is "active" and Task3 is "ready".  Now Task1 becomes ready, then active and preempts Task2.  When Task1 is finished will the scheduler guarentee a return to Task2 or might Task3 run instead?  Is there any option to ensure that Task2 runs over Task3 until Task2 hits a blocking call?

Pmt

[c0170]

Hi pmt,

reply to your first post. Task1 with higher priority preempts Task2 (assumption is this task hasn't completed it's job) . After Task1 finishes, Task2 will continue where it was interrupted/preempted.

Regards,

MartinK

[pmt]

Thanks Martin.  This is good news.  

Is this documented anywhere as a specified behavior, or is this just the way it happens to be?  I just don't want this changing in the future.

Regards,

pmt   

[DavidS]

Hi pmt,

Study material can be found off the Freescale Technology Forum (FTF) link.

Goto:

http://www.freescale.com/webapp/sps/site/overview.jsp?code=FTF_OLLTABLE 

Do a "Title" search on "MQX".

Multiple good classes on MQX can be had.

Hope this helps.

Regards,

David

[c0170]

Hi pmt,

it's how  preemptive scheduling works. Read some literature to understand this behavior.

Regards,

MartinK

[pmt]

This is not an attribute you can universally assign to any scheduler calling itself preemptive, rather this is a scheduling policy question.  As a counter example RTX (Keil/ARM) does not guarantee the preempted task (Task2) will run over Task3 if both Task2 and Task3 are in the "ready" state when Task1 blocks.  Rather, depending on which task is first in its task list, that one will run.  

As stated before MQX supports FIFO scheduling as a configurable policy in which the task (at the same priority) waiting the longest will run first, but I don't see any explicit policy that will allow me to guarantee the continuation of the task that was preempted (i.e.. waiting the shortest) to resume over other "ready" tasks at the same priority level.

Pmt      

[pavel_chromy]

As you stated, you request such scheduler behaviour to avoid concurrent access to data structures shared among tasks with the same priority.

Simple answer: use mutex or semaphore as these are the instruments designed for this. I do not see any reason so far for not using locking mechanism. I consider relying on scheduler behaviour a hack.

Best regards,

  Pavel

[pmt]

The scheduler can be relied on for many features and behaviors as it relates to application code that I wouldn't consider a hack.  If this was not the case then there would be no configuration options concerning scheduling policy, and no reason to configure it.  But I do agree that relying on a behavior that is not documented, overt, and guaranteed by design is a hack.  It was the purpose of my original question to flush this out.     

I think the answer is that the scheduling policy I was asking about is not specified so mutual exclusion objects are a must in my senerio.  Thanks all for the help!

Best Regards,

pmt

[admin]

I haven't tested this, but I can tell you that I've never seen an OS guarantee what you are asking.  Typically, one or two things need to be understood to achieve what you would like ensured:

1. Order the task template list properly to allow the scheduler to see the task (TASK2_PRI(6)) first when ready.  This is due to the way the OS normally scans through the task list.
2. If you do not auto start the tasks in question, you may have to know the order tasks were executed to know how the OS keeps it's own internal list.

A simple test should be able to determine how MQX handles this presently, but it could change in the future...

[pmt]

It's not so much that I want Task2 prioritized first, rather I want the task that was preempted to resume first over other tasks at the same priority level.  MQX currently supports the option of tasks FIFO's... that is the task that was "waiting" the longest runs first.  What I want is the option of a LIFO behavior so the task that was running last is the first to resume.

There is quite a bit of novelty in guaranteeing this behavior.   I can have data structures shared by tasks at the same priority level.  As long as I do my read-modify-writes on these data structures before calling a blocking function then I can forgo any explicit semaphore protection on the structures.  I'm basically using the scheduler in an optimum way to provide mutual exclusion and have no overhead of explicit mutex calls.

pmt