Тут на прошлой неделе довелось мне домашними делами заняться. В общем, 3 дела было, причем каждое из них делаться могло урывками — часть сделал, подождал результата, потом следующую часть и т.д.
Как программист, решил делать все это в многопоточном режиме. Естественно, делать дело A в паузах B или C не получилось. Так что иногда прерывал А в середине очередного кванта , отвлекался на B, потом возвращался к А и т.д. Критерий — закончить все 3 дела как можно быстрее .
Не скажу, что алгоритм был оптимальный. Уж одно точно — предварительное планирование не проводилось . Действовал по принципу реакции на ситуацию — в каждый момент решал, что лучше — отвлечься от А и переключиться на В, или пусть В подождет, потом в А будет большая пауза (знаю), вот тогда В и займемся. И т.д.
Сделал все и подумал. А что, если бы в соседней комнате кто-то сидел и не видя, что я сейчас делаю, мне команды давать начал , типа "брось А, переходи к В" и т.д. Ну то. что я бы от таких команд озверел — ладно, не в этом дело. Но вот закончил бы я скорее всего намного позже. Мне-то лучше знать, когда чем стоит заниматься.
А вот в Windows мы именно так себя и ведем. Передоверили ОС все планирование и надеемся на ее мудрость. А она, между прочим, эту мудрость в рамках системы реализует, а не моего процесса. А мне бы интересно свой процесс пооптимальнее сделать.
Только не надо мне про приоритеты потоков говорить. Устанавливать их надолго — неприлично это, потому как это не один ваш поток за
счет другого берет, а берет он за счет всех (многих, по крайней мере) других потоков.
А между тем в Win API есть средство для ручного шедулинга — фиберы. Вот, цитирую
A fiber is a unit of execution that must be manually scheduled by the application. Fibers run in the context of the threads that schedule them. Each thread can schedule multiple fibers. In general, fibers do not provide advantages over a well-designed multithreaded application. However, using fibers can make it easier to port applications that were designed to schedule their own threads
и , похоже, результат его можно занести в книгу рекордов RSDN, если такая появится (а кстати, не сделать ли ?). 100% единодушие — фиберы не использует никто.
(В скобках — весьма существенный фактор. что их нет в 9x. Но и те, кто пишет программы для NT только, сервисы, к примеру, их, видимо, тоже не использует)
Я не агитирую за фиберы . Отнюдь нет. Я их тоже не использовал никогда. Меня другое интересует — есть ли рациональное зерно в том. чтобы взять управление шедулингом на себя в Windows. Подчеркиваю, именно в Win32 и обычных языках (С++, Pascal, VB), о всяких языках с внутренней поддержкой многопоточности я предлагаю здесь не говорить.
Сам шедулинг устроить не сложно. К примеру, через таймер, как ОС и делает у себя внутри. Получаем сигнал от таймера и переключаемся на тот фибер, который, по нашему мнению, больше всего сейчас достоин. Иными словами, на приоритеты и квантование в ОС мы не посягаем, сколько времени дадут, столько и дадут, но вот распорядиться им попробуем сами, а не предоставим это ОС.
PD>и , похоже, результат его можно занести в книгу рекордов RSDN, если такая появится (а кстати, не сделать ли ?). 100% единодушие — фиберы не использует никто.
Кстати, насчет своего шедулера — написать хороший шедулер не так просто. Кстати, кроме шедулера придется реализовать самому примитивы синхронизации. Но результат того стоит. В ряде случаев.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кто что думает ?
В подавляющем количестве систем они бессмыслены. Имеет смысл только для систем с балансировкой нагрузки для задач, что большая редкость. Вообще, многопоточность — вещь конечно хорошая, но стремная. Легко сделать ошибку, но очень сложно ее отловить. Поэтому лучшая программа это та, которая локализует ее воздействие в определенных местах, и как можно меньше вмешивается в ее работу.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот в Windows мы именно так себя и ведем. Передоверили ОС все планирование и надеемся на ее мудрость. А она, между прочим, эту мудрость в рамках системы реализует, а не моего процесса. А мне бы интересно свой процесс пооптимальнее сделать.
Я что-то не понимаю, а в других ОС не так обстоят дела?
PD>Сделал все и подумал. А что, если бы в соседней комнате кто-то сидел и не видя, что я сейчас делаю, мне команды давать начал , типа "брось А, переходи к В" и т.д. Ну то. что я бы от таких команд озверел — ладно, не в этом дело. Но вот закончил бы я скорее всего намного позже. Мне-то лучше знать, когда чем стоит заниматься.
PD>А вот в Windows мы именно так себя и ведем.
К сожалению, это кривая аналогия. Не так мы себя ведем. Это коммунальная квартира с толпой жильцов, которые совместно используют ограниченное количество ресурсов. И каждый из них представления не имеет о том, какие задачи стоят перед остальными. Жильцы могут договориться о некоторых правилах (туалет надолго не занимать). Но один злонамеренно или случайно нарушивший правила блокирует всех остальных. PD>Передоверили ОС все планирование и надеемся на ее мудрость. А она, между прочим, эту мудрость в рамках системы реализует, а не моего процесса. А мне бы интересно свой процесс пооптимальнее сделать.
Делай — кто тебе запрещает? Система рулит тобой на уровне "стой" — "беги". А уж чем тебе при этом "беги" заниматься — лично твое дело. PD>А между тем в Win API есть средство для ручного шедулинга — фиберы.
Есть. PD>Как раз получается ситуация, которую я описал. PD>Устроил я голосование PD>и , похоже, результат его можно занести в книгу рекордов RSDN, если такая появится (а кстати, не сделать ли ?). 100% единодушие — фиберы не использует никто. PD>(В скобках — весьма существенный фактор. что их нет в 9x. Но и те, кто пишет программы для NT только, сервисы, к примеру, их, видимо, тоже не использует)
Они нужны очень-очень-очень редко. PD>Я не агитирую за фиберы . Отнюдь нет. Я их тоже не использовал никогда. Меня другое интересует — есть ли рациональное зерно в том. чтобы взять управление шедулингом на себя в Windows.
Для ответа на этот вопрос надо задаться другим вопросом: "а нафига вообще нужен шедулинг?" И тогда станет понятно, что собственно вся идея шедулинга — в том, чтобы обеспечить эффективное использование ресурсов. И "тонкое руление" в этом смысле не особенно лучше, чем "толстое". Я спрашивал как-то на лекциях по ОС, не стоит ли применять в шедулере более продвинутые алгоритмы, чем LRU и "кто не ждет на блокировке, того и пустим". Оказалось, что нет, т.к. расходы на управление превышают выигрышь.
Основное рациональное зерно в ручном управлении шедулингом состоит в минимизации переключений потоков. Винда, действительно, имеет очень ограниченное представление о сути деятельности переключаемого потока. Поэтому ей приходится делать операцию переключения достаточно дорогостоящей. В некоторых частных случаях может оказаться эффективнее использовать фиберы, т.к. переключение фибера гораздо дешевле. Ну и сами расходы на фибер меньше.
Тем не менее, примеров приложений, которые их используют, очень мало.
Вообще многопоточных приложений пока что мало (исключая сервера, которые построены в рамках фреймворков со встроенным обеспечением многопотоковости). Потому что сложно это — многопотоковое приложение написать. Головой думать больше приходится. Я вот никак не мог этого сделать, пока не начал с SQL работать — потому, что там как раз все можно в действии отследить, и все зависимости увидеть, и т.п.
А с файберами надо о еще более низком уровне думать. Обычно овчинка не стоит выделки.
PD>Сам шедулинг устроить не сложно. К примеру, через таймер, как ОС и делает у себя внутри. Получаем сигнал от таймера и переключаемся на тот фибер, который, по нашему мнению, больше всего сейчас достоин.
Очень-очень наивное представление о том, как это сделать. Во-первых, файберы сами по себе кооперативны, и сделать вытесняющий шедулер на их основе невозможно. Во-вторых, собака зарыта внутри "больше всего сейчас достоин". Нужна конкретная идея, как вычислять этот размер достоинства. А также аргументация того, что этот алгоритм будет грузить ресурсы эффективнее, чем стандартный алгоритм шедулера в винде (а там, кстати, AFAIK, используется довольно-таки нетривиальная механика). Если нет ни того, ни другого, то использование фиберов — это способ бездарно убить свое время.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>и , похоже, результат его можно занести в книгу рекордов RSDN, если такая появится (а кстати, не сделать ли ?). 100% единодушие — фиберы не использует никто.
иногда используют
PD>(В скобках — весьма существенный фактор. что их нет в 9x. Но и те, кто пишет программы для NT только, сервисы, к примеру, их, видимо, тоже не использует)
вообще то их нет только в Win95, в 98 и выше они есть.
PD>Я не агитирую за фиберы . Отнюдь нет. Я их тоже не использовал никогда. Меня другое интересует — есть ли рациональное зерно в том. чтобы взять управление шедулингом на себя в Windows. Подчеркиваю, именно в Win32 и обычных языках (С++, Pascal, VB), о всяких языках с внутренней поддержкой многопоточности я предлагаю здесь не говорить.
А что не нравится? при желании и сейчас можно писать многопоточные программы используя только фиберы. Но по моему нужны оба варианта и нормальные и легкие потоки. Некторые вещи очень хорошо ложатся на легкие потоки и сопрограммы, а для других просто не обойтись без тяжелых потоков.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Кто что думает ? GZ>В подавляющем количестве систем они бессмыслены. Имеет смысл только для систем с балансировкой нагрузки для задач, что большая редкость. Вообще, многопоточность — вещь конечно хорошая, но стремная. Легко сделать ошибку, но очень сложно ее отловить. Поэтому лучшая программа это та, которая локализует ее воздействие в определенных местах, и как можно меньше вмешивается в ее работу.
Когда пишешь с использованием легких потоков (фиберы, генераторы в скриптовых языках) логика совсем другая, есть полный контроль над потоком управления и вероятность ошибок гораздо меньше чем для "нормальных" потоков.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Сделал все и подумал. А что, если бы в соседней комнате кто-то сидел и не видя, что я сейчас делаю, мне команды давать начал , типа "брось А, переходи к В" и т.д. Ну то. что я бы от таких команд озверел — ладно, не в этом дело. Но вот закончил бы я скорее всего намного позже. Мне-то лучше знать, когда чем стоит заниматься.
PD>>А вот в Windows мы именно так себя и ведем. S>К сожалению, это кривая аналогия. Не так мы себя ведем. Это коммунальная квартира с толпой жильцов, которые совместно используют ограниченное количество ресурсов. И каждый из них представления не имеет о том, какие задачи стоят перед остальными. Жильцы могут договориться о некоторых правилах (туалет надолго не занимать). Но один злонамеренно или случайно нарушивший правила блокирует всех остальных.
+1. Но я, может быть, неудачено выразился. Я имею в виду, что в рамках того времени, которое нам Windows отдает, мы ей позволяем решать, когда какому из наших потоков что делать. А то, что мы могли бы у чужих потоков время позаимствовать — это и так ясно.
PD>>Передоверили ОС все планирование и надеемся на ее мудрость. А она, между прочим, эту мудрость в рамках системы реализует, а не моего процесса. А мне бы интересно свой процесс пооптимальнее сделать. S>Делай — кто тебе запрещает? Система рулит тобой на уровне "стой" — "беги". А уж чем тебе при этом "беги" заниматься — лично твое дело.
Так я об этом и говорю
PD>>(В скобках — весьма существенный фактор. что их нет в 9x. Но и те, кто пишет программы для NT только, сервисы, к примеру, их, видимо, тоже не использует) S>Они нужны очень-очень-очень редко.
Или же о них просто мало кто знает
поиск по RSDN
поток 93495
фибер 41
PD>>Я не агитирую за фиберы . Отнюдь нет. Я их тоже не использовал никогда. Меня другое интересует — есть ли рациональное зерно в том. чтобы взять управление шедулингом на себя в Windows. S>Для ответа на этот вопрос надо задаться другим вопросом: "а нафига вообще нужен шедулинг?" И тогда станет понятно, что собственно вся идея шедулинга — в том, чтобы обеспечить эффективное использование ресурсов. И "тонкое руление" в этом смысле не особенно лучше, чем "толстое". Я спрашивал как-то на лекциях по ОС, не стоит ли применять в шедулере более продвинутые алгоритмы, чем LRU и "кто не ждет на блокировке, того и пустим".
Есть разница. Хоть какой алгоритм применяй в ОС — ОС не знает и не может знать, чем потоки занимаются сейчас. Ну разве что за вычетом потоков из System . Поэтому она с ними вынуждена обращаться по принципу "всем сестрам по серьгам", пока, конечно, приоритеты не поставлены. Вот представь себе ОС, которая только на себя работает, т.е. весь исполняемый в ней код — ее собственный код . Авторы такой ОС, может быть и вытесняющую многопоточность делать не будут вообще — просто шедулер будет принимать решение, какой код сейчас выполнять. Потому что, собственно говоря, и потоков как таковых не будет (я имею в виду не объект ядра, а идею).
PD>>Сам шедулинг устроить не сложно. К примеру, через таймер, как ОС и делает у себя внутри. Получаем сигнал от таймера и переключаемся на тот фибер, который, по нашему мнению, больше всего сейчас достоин. S>Очень-очень наивное представление о том, как это сделать. Во-первых, файберы сами по себе кооперативны, и сделать вытесняющий шедулер на их основе невозможно.
Именно. И не надо. Кооперативная многозадачность вообще-то эффективнее. Она по другим причинам неприемлема в рамках ОС, но не внутри моего процесса. Внутри него мне не надо вытесняющей многозадачности. Смысла нет — зачем мне вытеснять случайным образом, когда можно принять решение на основе имеющейся информации. Мой процесс-то, в отличие от ОС, хорошо знает, какой фибер у него чем занимается и в каком у него состоянии дела.
>Во-вторых, собака зарыта внутри "больше всего сейчас достоин". Нужна конкретная идея, как вычислять этот размер достоинства.
Эта идея может быть только в рамках той задачи, которая реализуется. Грубо говоря — если Вы набираете команду для постройки дома, то как руководитель Вы и решаете, куда сейчас основные ресурсы бросить сейчас, а куда потом, так, чтобы в итоге дом был быстрее построен. И совсем не уверен, что этот опыт Вам прямо пригодится, если Вы наберете команду поваров и дадите им заданме изготовить обед для приема . В общем, сетевое планирование и т.д.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Потому что, собственно говоря, и потоков как таковых не будет (я имею в виду не объект ядра, а идею). PD>>>Сам шедулинг устроить не сложно. К примеру, через таймер, как ОС и делает у себя внутри. Получаем сигнал от таймера и переключаемся на тот фибер, который, по нашему мнению, больше всего сейчас достоин. S>>Очень-очень наивное представление о том, как это сделать. Во-первых, файберы сами по себе кооперативны, и сделать вытесняющий шедулер на их основе невозможно.
PD>Именно. И не надо. Кооперативная многозадачность вообще-то эффективнее. Она по другим причинам неприемлема в рамках ОС, но не внутри моего процесса. Внутри него мне не надо вытесняющей многозадачности. Смысла нет — зачем мне вытеснять случайным образом, когда можно принять решение на основе имеющейся информации.
Гм. Ты точно говоришь о той вытесняющей многозадачности, о которой я? Она характеризуется вовсе не случайностью вытеснения. А тем, кто принимает решение. В кооперативной многозадачности решение о передаче управления принимает поток. А в вытесняющей — шедулер. PD>Мой процесс-то, в отличие от ОС, хорошо знает, какой фибер у него чем занимается и в каком у него состоянии дела.
Это все словоблудие, пока мы не определили понятия "знает", "состояние", "дела". PD>Эта идея может быть только в рамках той задачи, которая реализуется. Грубо говоря — если Вы набираете команду для постройки дома, то как руководитель Вы и решаете, куда сейчас основные ресурсы бросить сейчас, а куда потом, так, чтобы в итоге дом был быстрее построен. И совсем не уверен, что этот опыт Вам прямо пригодится, если Вы наберете команду поваров и дадите им заданме изготовить обед для приема . В общем, сетевое планирование и т.д.
Не надо рассуждений про поваров и строителей. Может, есть какой-то готовый пример задачи, с которой
а) виндовый шедулер справляется недостаточно хорошо,
б) есть способ написать свой лучший шедулер?
На таком уровне рассуждений мы ни к чему не придем. Потому, что ответ на вопрос "А могут ли существовать ситуации, когда существует более эффективный способ управлять ресурсами системы, чем отдавать управление шедулеру" — "да, могут". Но пользы в нем 0. Могут, ну и что? Может, их на практике не встречается.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Sinclair wrote:
> На таком уровне рассуждений мы ни к чему не придем. Потому, что ответ > на вопрос "А могут ли существовать ситуации, когда существует более > эффективный способ управлять ресурсами системы, чем отдавать > управление шедулеру" — "да, могут". Но пользы в нем 0.Могут, ну и что?
Ну во-первых, не нужна синхронизация (так как волокна не работают
параллельно). Во-вторых, с помощью волокон можно делать сопрограммы.
В-третьих, волокон может быть МНОГО без всякой дополнительной нагрузки
на планировщик.
Здравствуйте, Sinclair, Вы писали: PD>>Именно. И не надо. Кооперативная многозадачность вообще-то эффективнее. Она по другим причинам неприемлема в рамках ОС, но не внутри моего процесса. Внутри него мне не надо вытесняющей многозадачности. Смысла нет — зачем мне вытеснять случайным образом, когда можно принять решение на основе имеющейся информации.
S>Гм. Ты точно говоришь о той вытесняющей многозадачности, о которой я? Она характеризуется вовсе не случайностью вытеснения. А тем, кто принимает решение. В кооперативной многозадачности решение о передаче управления принимает поток. А в вытесняющей — шедулер.
Помнится мне, в Windows 3.11 поток мог принять решение, что никому он не передаст управление
Здравствуйте, Cyberax, Вы писали:
C>Ну во-первых, не нужна синхронизация (так как волокна не работают C>параллельно).
Гм. Вот тут есть некоторое непонимание с моей стороны. Если фибер не работает параллельно, то нафиг он вообще такой нужен? А если фиберы все таки работают параллельно, то нужны какие-то примитивы синхронизации. C> Во-вторых, с помощью волокон можно делать сопрограммы.
С этим у меня в голове сложнее. Я не вполне понимаю, что такое сопрограммы, и, по-моему, без поддержки со стороны языка программирования сочинять их крайне трудно. C>В-третьих, волокон может быть МНОГО без всякой дополнительной нагрузки C>на планировщик.
Ну как же без нагрузки? Мы же собираемся писать свой планировщик, верно? Потому что без планировщика фиберы вряд ли смогут работать согласованно.
Я понимаю, что наш планировщик может работать дешевле системного. Вопрос — насколько.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, oleksab, Вы писали:
O> Помнится мне, в Windows 3.11 поток мог принять решение, что никому он не передаст управление
Совершенно верно. В три-одиннадцатой была кооперативная многозадачность.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
PD>>Сам шедулинг устроить не сложно. К примеру, через таймер, как ОС и делает у себя внутри. Получаем сигнал от таймера и переключаемся на тот фибер, который, по нашему мнению, больше всего сейчас достоин. S>Очень-очень наивное представление о том, как это сделать. Во-первых, файберы сами по себе кооперативны, и сделать вытесняющий шедулер на их основе невозможно.
Во-первых, ты не прав — это на самом деле сделать возможно. Достаточно шедулер (или его часть) запустить в другом потоке, который будет делать отсечку по времени, и все. Видишь ли в чем дело — SwitchToFiber можно вызывать из другого потока — это совсем не обязательно делать из активного файбера.
Тут есть минус и плюс. Плюс в том, что можно сделать шедулер, накладные издержки которого не зависят от количества файберов. Минус — потребуется два переключения контекста для переключения одного файбера.
Далее, хочу заметить, что невытесняющий характер многозадачности — это на самом деле огромный плюс, как это ни странно. Приложение писать, отлаживать, и верифицировать гораздо проще, если количество мест, в котором поток может прерваться ограничено, и ты их знаешь. Если подойти к делу с умом — станет ясно, что от большей части кода не требуется реентерабельности. Что очень круто.
S>Во-вторых, собака зарыта внутри "больше всего сейчас достоин". Нужна конкретная идея, как вычислять этот размер достоинства. А также аргументация того, что этот алгоритм будет грузить ресурсы эффективнее, чем стандартный алгоритм шедулера в винде (а там, кстати, AFAIK, используется довольно-таки нетривиальная механика).
Ресурсы, т.е. CPU, "эффективнее" нагрузить нельзя. Этот аргумент вообще идет мимо — он не из той области. Можно нагрузить поровну, или дать кому-то приоритет .
S>Если нет ни того, ни другого, то использование фиберов — это способ бездарно убить свое время.
Синклер, если мозгов в голове нет, то любое занятие — отличный способ бездарно убить время. Ты зачем это написал — Дворкина подозреваешь в идиотизме? Или хочешь предостеречь от опрометчивого шага программеров-идиотов? Так как это бесполезно, я тебе лучше порекламирую файберы.
"Пробовал ли ты? А ты попробуй!" Тебе надоели тред-пулы? Задолбали "паттерны" параллельного проектирования? Хочется чтоб алгоритмы выглядели по человечески — свой "поток" на каждую истинно параллельную активность в системе? Чтобы их крутились десятки тысяч, и все было нормально? Нет времени и желания рефакторить старый код, чтобы он стал thread-safe? Тогда пиши свой файберный планировщик, в котором любая операция O(1) — задачка, скажу тебе, не слишком простая , но и не очень сложная — я уложился в 468 строк на С++.
Sinclair wrote:
> C>Ну во-первых, не нужна синхронизация (так как волокна не работают > C>параллельно). > Гм. Вот тут есть некоторое непонимание с моей стороны. Если фибер не > работает параллельно, то нафиг он вообще такой нужен?
Для сопрограмм, например.
> А если фиберы все таки работают параллельно, то нужны какие-то > примитивы синхронизации.
В этом случае нужны.
> C> Во-вторых, с помощью волокон можно делать сопрограммы. > С этим у меня в голове сложнее. Я не вполне понимаю, что такое > сопрограммы, и, по-моему, без поддержки со стороны языка > программирования сочинять их крайне трудно.
Простейший пример сопрограмм — это yield в C# 2.
> C>В-третьих, волокон может быть МНОГО без всякой дополнительной нагрузки > C>на планировщик. > Ну как же без нагрузки? Мы же собираемся писать свой планировщик, верно?
Не обязательно писать планировщик (например в случае с сопрограммами).
Здравствуйте, Sinclair, Вы писали:
S>...А также аргументация того, что этот алгоритм будет грузить ресурсы эффективнее, чем стандартный алгоритм шедулера в винде (а там, кстати, AFAIK, используется довольно-таки нетривиальная механика). Если нет ни того, ни другого, то использование фиберов — это способ бездарно убить свое время.
Мне кажется, что у уважаемого Pavel-а Dvorkin-а одна из главных задач — убить свое время. Он все время интересуется разными тонкими вопросами которые по сути интереса не представляют. Основной его посыл "нужно экономить на всем". Жаль что в это "все" не входит собственное время и время окружающих.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
PD>>поток 93495 PD>>фибер 41
ANS>добавь еще "файбер" и "fiber"
Еще зеленые и легкие потоки (причем как по-русски, так и по-английски), ну, и нужно вспомнить, что потоками называют еще ручу вещей вроде потоков вода-вывода.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Sinclair wrote:
>> На таком уровне рассуждений мы ни к чему не придем. Потому, что ответ >> на вопрос "А могут ли существовать ситуации, когда существует более >> эффективный способ управлять ресурсами системы, чем отдавать >> управление шедулеру" — "да, могут". Но пользы в нем 0.Могут, ну и что?
C>Ну во-первых, не нужна синхронизация (так как волокна не работают C>параллельно).
Еща как нужна. Только другая. Да и параллельно они работать потенциальном огут, так как могут быть запущены на разных потоках.
C> Во-вторых, с помощью волокон можно делать сопрограммы.
Это одно и тоже. Просто левая терминология. Как в рочем волокнами часто называют потоки.
C>В-третьих, волокон может быть МНОГО без всякой дополнительной нагрузки C>на планировщик.
Естественно. Ведь они не выполняются автоматом пареллельно. Переключение контекста потокв дело конечно дорогое, но при этом обеспечивается параллельная работа (хотя бы ее эмуляция). Файберы же это урощенный контекст который может быть приостановлен и возобнавлен.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
, отвлекался на B, потом возвращался к А и т.д. Критерий — закончить все 3 дела как можно быстрее 
1.1.4 stable rev. 510
— это совсем не обязательно делать из активного файбера.
