Как не крути а процессор один, и для него любая программа будет одной задачей.
Вопрос в абстрагировании. Ниже приведено две реализации одного и того же:

1)


2)


Пусть памяти всего 1KB, и есть 3 таска. Во втором варианте каждый таск может запросто взять и пользовать например 512 байт под временный буфер, в первом же 3x512B > 1KB и приехали.


Дайте каждой задаче static контекст с которым она работает, оформите как обычную функцию, массивные временные переменные/буферы выделяйте в стеке, и вызывайте их все поочереди(и/или по условию) и получите много задач, "параллельно" выполняющихся (находящихся в разной стадии исполнения), плюс оптимальное распределение памяти.

Контекст в виде структуры с передачей указателя на него - получите возможность параллельного исполнения одинаковых задач.

Так очень неудобно код писать. Что делать если хочется посидеть в do_stuff() примерно минуту ?
Static - это необоснованный расход памяти.
Вот пример:

Пусть в каждой фунции func1...func8 есть локальные переменные по 100 байт в каждой. Если все staticами объявить, то Thread1 800 байт памяти отъест, если auto - то всего 100 байт.

Может быть у нас терминология не совпадает? Я так понимаю, что задачи в вытесняющей ОС - это эквивалент Thread в программировании под Windows. А задачи в кооперативной ОС - это эквивалент Fiber. Я правильно понимаю?

С этим согласен, а пример не очень понятный.



Во первых если задаче надо так много памяти то очень вероятно, что она долго не будет возвращать управление системе. Во вторых если в системе много ввода/вывода, то что регулярно делать if (data_ready) do_stuff() ? не лучше ли wait_for_event() который блокирует задачу (выводит из планирования), а потом в прерывании она снова ставится в очередь. Так и код проще выглядит.

Например сделать свою реализацию ks_wait() / ks_yeild() - которая будет запускать оставшиеся задачи прямо из текущей.
Есть конечно и другой вариант, - разбить do_stuff() на две части, и запускать вторую часть через минуту после первой.


Именно. А Вы же собрались стек статически распределить. Плюс вероятно еще и контекст регистров каждого таска хранить, статически.
В Вашем случае потерь памяти будет куда больше, чем если просто выделить ровно столько памяти сколько нужно для полезных данных.


Не нужно бездумно объявлять все статиками. Делайте статиком только, то что должно быть статиком.

Например задача обработки принятого пакета данных - вырождается в
1. вынуть пакет из очереди,
2. обработать
3. засунуть в другую очередь.
4. Гото 1.
Сколько же нужно данных хранить статически для этой задачи? Помоему очевидно, если обеспечить непрерывное выполнение с п.1. до п.3. то статически хранить потребуется всего лишь два указателя на входную и выходную очереди.


И да и нет. Насчет первого утверждения - сравнение Thread с таском вытесняющей ОС подходящее.

Что же касается сравнения с Fiber в кооперативной ОС, ну не совсем оно то, хотя близко:

1. Никто не заставляет App управлять процессом, процессом запуска (schedule'ом) может заниматься ядро ОС, задача лишь обязана вернуть управление этому ядру -
либо нативно - выход из функции, либо непосредственным вызовом соответствующей системной функции.
2. Никто не заставляет наделять задачу в кооперативной ОС своим стеком. В связи с тем, что задача сама отдает управление ОС когда ей удобно, - все задачи могут ужиться с одним общим стеком.


Почему же, вот примеры где может потребоваться большой буфер, но не нужно много времени:

- банальный ping
- чтение/запись внешней флешки
- обработка модбас пакета

и т.д. все где имеет место запрос-ответ.


Бесспорно так лучше, абсолютно согласен.
Но это же концепции не меняет, соответвующий if просто уйдет "в недра" планировщика, а задача будет состоять из одного только do_stuff().

ks_run( do_stuff, &do_stuff_context, <event_id>, <timeout> );

Когда в кооперативной многозадачке изнутри таска надо отдать управление, вызывается system()

Ранжирование задач по приоритету - чаще всего достаточная мера для исключения рекурсивного вызова задачи , которая в данный момент может отдать управление. Если же есть перекрестные вызовы внутри задач одного приоритета, приходится в каждой задаче городить семафор.