21

Recently I was understanding for how threads are different from fibers. This answer says that

Threads use pre-emptive scheduling, whereas fibers use cooperative scheduling.

In order to get more information about cooperative multitasking vs preemptive multitasking there no specific post on SO. Hope that this question will be helpful to get all the information about the topic.

Mayur
  • 2,583
  • 16
  • 28
  • More or less the same difference you have between forceful community service and volunteering. The first forces threads to share something, the second leave the choice of sharing to a single thread that, if wants can keep the resource for itself forever. – Davide Spataro Apr 16 '19 at 08:09
  • So, Is it recommended to use cooperative multitasking real-time applications? – Mayur Apr 16 '19 at 08:11
  • 1
    No, it has terrible I/O performance. – Martin James Apr 16 '19 at 13:18
  • I think the real situation is somehow in the middle, there is no one or the other. The real multitask systems will let your code to coop with each others, if your program works correctly, but if your code tries to get all CPU resources, the multitask system will preemptive grab and put the code to sleep and will schedule for later execution. – minus one Dec 16 '19 at 13:28

2 Answers2

39

Short answer:

Preemptive: threads do not decide when to run and are forced to share the CPU

Cooperative: each thread, once running decides for how long to keep the CPU, and (crucially) when it is time to give it up so that another thread can use it.

Long Answer

Preemptive

It means that threads are not in control on when and/or for how long they are going to use the CPU and run. It is the scheduler (a component of the OS) that decides at any moment which thread can run and which has to sleep. You have no strong guarantees on what will be the next time a thread will run, and for how long. It is completely up to the scheduler.

Cooperative

In cooperative multitasking, what happens is that the scheduler has no say in when a thread can run. Each thread decides for how long it keeps the CPU. If it decided not to share the CPU with any other thread, then no other threads will run causing what is known as starvation.

Note that stopping one thread and starting another incurs in a certain amount of overhead. It means that you spend time and resources not to execute code from your tasks, but purely for the sake of enabling sharing the CPU. In certain real-time low latency application (like high frequency trading), this can be quite unacceptable.

Davide Spataro
  • 7,319
  • 1
  • 24
  • 36
2

Cooperative multitasking is great for embedded systems. As you normally would create a event handler in main.c and only let IRQ pass flags over to this, instead of actually running this code in the ISR. So if you expand the event handler to also allow RTC counter to let each task sleep and tell it to come back in 1ms or 60sec, great for battery life, as you sleep as often as possible even if just for 5ms.

You can't NOT have hard-waits, so your tasks have to be like state-machines, tell it to come back right away or in 5ms intervals etc.

I wrote my own OS in under 1K that does this.

Tony Philipsson
  • 21
  • 2