Connect with us

Preemptive Priority scheduling

Discussion in 'Microcontrollers, Programming and IoT' started by champ1, May 11, 2021.

Scroll to continue with content
  1. champ1


    Jul 17, 2018
    In preemptive scheduling there is timer running whose jobs is to switch tasks according to priority. scheduler decide which task will run and for how much time it will run on the CPU.

    What we should know before to design Preemptive System ?

    I think We should know how much time each tasks takes to complete its process and priority of each tasks.
  2. Harald Kapp

    Harald Kapp Moderator Moderator

    Nov 17, 2011
    Waiting for as long as it takes a task to complete its job negates the use of preemptive scheduling. Preemptive scheduling is there to allocate cpu time to each task. It therefore will interrupt running tasks even if they are not finished.
    Of course you need to know the priorities to assign them correctly to tasks.
  3. shumifan50


    Jan 16, 2014
    Preemptive scheduling is not a good option in most microcontroller applications. This is because many 'tasks' are time critical and cannot/should not be interrupted. It is also resource intensive, which most mc cannot afford. A better solution is 'cooperative multi tasking' where control is given up by each task at a suitable point in its processing. I have found that implementing this with state machines is quite easy by using a state variable for each task to determine the next processing for the task and an overall state to determine which task to give control to. Each task can then control when to relinquish control allowing a sort of variable number of tasks with each task with a variable time slice as needed. The overall state can then take time slicing into account when scheduling the next task to run.
  4. Nanren888


    Nov 8, 2015
    Another thing to consider related to being thread-safe. Anything that gets interrupted has to be ok with it and also with other things running in the meantime, including, perhaps another process calling the same code. Two processes might update the state of the same hardware with conflicting results. INterruption can bring issues of race conditions; checking a flag, being interrupted, then coming back to do something thinking it is safe because the last thing we did was check the flag, but in fact other processes have been running and changing the state of things since. This tends to mean that you have parts of the code that are atomic, effectively done as one operation, not interrupted and others that are not.
    If you are building, designing, in control of all the code, then coopertaive can be easier in the long run. If you have to run code from others, then preemptive may have to be considered.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day