Здравствуйте, Andrei N.Sobchuck, Вы писали:

VD>>Это все синонимы. Подразумевается что это замена потоков на базе кооперативной многозадачности. А в кооперативной многозадачности роль шедулера выполняют сами "потоки". Они сами принимают решение когда они могут отдать управление.

ANS>Не. Вот

Автор: Gaperton
Дата: 21.10.05

Gaperton всё объяснил.

Так, а что "нет"? Он сказал что-то новое?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну если (не на сервере) у тебя постояннно крутится System, то что-то у тебя в системе не так. System Idle там крутиться в основном должен

Гы. System Idle — это текстовая строчка в таскменеджере. А крутится в момент простоя как раз шедулер. Как ты думашь где он находится.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, Gaperton, Вы писали:

G>Ок, объясняю по порядку — тут все просто.
G>1) Сначала выбранный поток "расслаивается" на файберы посредством специального вызова на этом самом потоке.
G>2) Далее — он продолжает свое выполнение в главном файбере.
G>3) Выполнение этого потока не останавливается, при этом ты можешь переключать ему активный файбер вызывая SwitchToFiber как из этого самого потока, так и из другого.
G>4) Если происходит выход из любой файбер-функции "расслоеного" потока, то этот поток завершает свою работу.
G>5) Файберы ты, понятное дело, можешь убивать. Причем, в отличии от обычных потоков, ты можешь корректно убить стек с отработкой деструкторов, пробросив снизу вверх исключение даже для не активного файбера. Что превращает убийство файбера в штатную и гражданскую ситуацию, в отличии от потоков.

Sorry за off-topic, но года 4 назад я копал эту тему и в результате сложилось совершенно другое мнение...
SwitchToFiber из другого потока приводил к падению всего процесса. Насколько помню — в MSDN где-то сказано, что его можно вызывать только из потока, в котором живет fiber.

вот простой тест на предмет убиения фибера из другого потока:

#define _WIN32_WINNT 0x0400
#include <windows.h>
#include <stdio.h>
#define Q_STACK_SIZE 4096
VOID CALLBACK FiberProc (PVOID lpParameter)
{
  puts ("FiberProc Start");
  ::ExitThread (666);
  puts ("FiberProc End");
}
LPVOID g_fib1 = 0;
LPVOID g_fib2 = 0;
int g_fdata1 = 1;
int g_fdata2 = 1;
int g_tdata  = 2000;
DWORD WINAPI ThreadProc (PVOID lpParameter)
{
  puts ("ThreadProc Start");
  g_fib1 = ::ConvertThreadToFiber (&g_fdata1);
  g_fib2 = ::CreateFiber (Q_STACK_SIZE, FiberProc, &g_fdata2);
  puts ("ThreadProc Deadlock");
  for (;;);
}
int main(int argc, char* argv[])
{
  DWORD tid = -1;
  HANDLE  htr = ::CreateThread (0l, Q_STACK_SIZE * 4, ThreadProc, &g_tdata, 0, &tid);
  ::Sleep (1000);
  puts ("Killing deadlocked thread...");
  ::SwitchToFiber (g_fib2); // Здесь мы падаем ;(
  puts ("Success");
  ::Sleep (1000);
  return 0;
}

Последнее, что выводится до падения это "Killing deadlocked thread..." Проблемма не в синхронизации, т.к. увеличение времени слипа в пред строке ничего не меняет.
Только-что проверил под W2K — результат тот-же что был и под NT 4.0...

Здравствуйте, IID, Вы писали:

IID>тогда, для симметрии, добавляем "thread", "многопоточность"

Чего заниматься гаданием на кофейной гуще? Не проще ли еще одно голосование создать?

Здравствуйте, Gaperton, Вы писали:

G>Спокойнее, Синклер спокойнее. Во-первых, мы-то с PD в курсе этих понятий — здесь все более или менее однозначно. Во-вторых, почитай чего-нибудь по планировщикам задач — это самый естественный и безболезненный способ разобраться. Любую книгу по операционным системам возьми — например Танненбаума. Ну, и подумай немного над задачей сам — тут все просто.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Устроил я голосование

PD>>http://www.rsdn.ru/poll/1273.aspx

Автор: Pavel Dvorkin
Дата: 12.10.05
Вопрос: Испоользовали ли Вы когда-либо фиберы (fibers) в своих программах ?

PD>>и , похоже, результат его можно занести в книгу рекордов RSDN, если такая появится (а кстати, не сделать ли ?). 100% единодушие — фиберы не использует никто.

G>Уже не 100%. Я проголосовал.

G>Отчет по файберам

Автор: Gaperton
Дата: 23.04.05

Файберы и потоки сравнивать ИМХО некорректно, хотя бы потому, что это несколько разные уровни ОС. Потоки — объекты ядра, а файберы — чисто user-mode абстракции. Более того, файберы крутятся внутри потока, который, в свою очередь, с точки зрения ядра является обычным планируемым потоком. Поэтому об преимуществах файберов над потоками говорить не имеет смысла. Возможно иногда и удобно разбить какую-то задачу на файберы, для удобства, но обработка все равно будет псевдопараллельной. А вот задачу, в которой необходимо 10К файберов, я что-то не могу себе представить.
Что касается серверов... в многопроцессорных системах смысл использования файберов лично мне вообще не ясен... Их же нельзя заставить работать на разных процах, то есть все равно прийдется создавать потоки на каждый проц. (???)

Здравствуйте, Pavel Dvorkin, Вы писали:

...

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

Да, не забудем про то, что дорожку то перед собой надо самому делать, откуда дорожниые рабочии знать, по какой дороге я хочу ехать. Будет такой у нас велосипел — путеукладчик.

ЗЫ По теме на подавляющем большинстве задач, которые решаются на ОС общего назначения ваши гм.. идеи приведут только к росту цены на ПО в геометрической прогресси.

ЗЗЫ В программировании есть множество подходов. Каждый имеет своих сторонников и противников, плюсы и минусы. Нельзя сказать, что вот ООП(к примеру) — это идеальный подход, применимый везде. Равно как и сказать что это отстой, фу, фтопку. Можно долго спорить о технологиях, приводить аргументы, соглашаться, не соглашаться.
Но (имхо конечно), подход "Зафигачить фигню, просто так, чтоб было, а потом посмотрим какое уродство мы родили, главное, что родили сами а не кто то другой" — это однозначно дурной и проигрышный подход.

Здравствуйте, Nickolay Ch, Вы писали:

Только одно не при чем тут велосипеды? Может ты темой ошибся?

Здравствуйте, Игoрь, Вы писали:


И>Файберы и потоки сравнивать ИМХО некорректно, хотя бы потому, что это несколько разные уровни ОС. Потоки — объекты ядра, а файберы — чисто user-mode абстракции. Более того, файберы крутятся внутри потока, который, в свою очередь, с точки зрения ядра является обычным планируемым потоком. Поэтому об преимуществах файберов над потоками говорить не имеет смысла. Возможно иногда и удобно разбить какую-то задачу на файберы, для удобства, но обработка все равно будет псевдопараллельной. А вот задачу, в которой необходимо 10К файберов, я что-то не могу себе представить.
И>Что касается серверов... в многопроцессорных системах смысл использования файберов лично мне вообще не ясен... Их же нельзя заставить работать на разных процах, то есть все равно прийдется создавать потоки на каждый проц. (???)

Мне достаточно того что фиберы позволяют легко реализовать на C++ ленивые вычисления и сопрограммы. А преимущества у фиберов над потоками одно, на порядок меньше граблей и если нет необходимости в настоящей многопоточности, то проще использовать фиберы

Здравствуйте, VladD2, Вы писали:

VD>>>Это все синонимы. Подразумевается что это замена потоков на базе кооперативной многозадачности. А в кооперативной многозадачности роль шедулера выполняют сами "потоки". Они сами принимают решение когда они могут отдать управление.

ANS>>Не. Вот

Автор: Gaperton
Дата: 21.10.05

Gaperton всё объяснил.

VD>Так, а что "нет"? Он сказал что-то новое?

В отличие от кооперативной многозадачности с фиберами возможно "внешнее" планирование.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Устроил я голосование

Голосование некорректное. Нет варианта "а что такое фибер?".

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Игoрь, Вы писали:


И>>Файберы и потоки сравнивать ИМХО некорректно, хотя бы потому, что это несколько разные уровни ОС. Потоки — объекты ядра, а файберы — чисто user-mode абстракции. Более того, файберы крутятся внутри потока, который, в свою очередь, с точки зрения ядра является обычным планируемым потоком. Поэтому об преимуществах файберов над потоками говорить не имеет смысла. Возможно иногда и удобно разбить какую-то задачу на файберы, для удобства, но обработка все равно будет псевдопараллельной. А вот задачу, в которой необходимо 10К файберов, я что-то не могу себе представить.
И>>Что касается серверов... в многопроцессорных системах смысл использования файберов лично мне вообще не ясен... Их же нельзя заставить работать на разных процах, то есть все равно прийдется создавать потоки на каждый проц. (???)

FR>Мне достаточно того что фиберы позволяют легко реализовать на C++ ленивые вычисления и сопрограммы. А преимущества у фиберов над потоками одно, на порядок меньше граблей и если нет необходимости в настоящей многопоточности, то проще использовать фиберы
Все зависит от решаемых задач. Например идут лесом длительные синхронные операции (а если не идут, то смысла использовать файберы я не вижу), в замен нужно использовать асинхронные. С одной стороны это может повысить эффективность (иногда), а с другой — есть усложнение. В принципе, синхронность наверное можно эмулировать через свой планировщик, но тут есть свои ограничения. Например, я не вижу, как тут можно использовать IOCP (видимо никак), о написании серверных приложений стоит забыть (разве что однопоточные псевдопараллельные), так как не можем использовать преимущества многопроцессорности.
Вообщем, как я понимаю, файберы можно использовать в рамках одного потока с целью упрощения его логики без существенного снижения эффективности. Как-то так.

Здравствуйте, Candle645, Вы писали:

C><skipped>
В main забыл вызвать ::ConvertThreadToFiber.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>В отличие от кооперативной многозадачности с фиберами возможно "внешнее" планирование.

В этом случае это уже превращается в "закат солнца в ручную".

Здравствуйте, VladD2, Вы писали:

ANS>>В отличие от кооперативной многозадачности с фиберами возможно "внешнее" планирование.

VD>В этом случае это уже превращается в "закат солнца в ручную".

Напомню, что в этом была и вся фишка

Здравствуйте, VladD2, Вы писали:

VD>System Idle — это текстовая строчка в таскменеджере.

Idle — отдельный процесс (Руссинович почему-то называет его "лжепроцесс", но своё адресное пространство у Idle есть). System — тоже отдельный процесс, в нём крутятся working threads ядра.

VD>А крутится в момент простоя как раз шедулер.

CPU выполняет команду halt (в процессе Idle) — просто ожидание прерывания от таймера.

VD> Как ты думашь где он находится.

AFAIK sheduler не имеет своего контекста выполнения (выполняется в контексте любого thread).

Мои ответы относятся к NT. В оригинале похоже о 9x, там проц всегда чем-то занят .

Здравствуйте, Sinclair, Вы писали:

S>Может, есть какой-то готовый пример задачи, с которой
S>а) виндовый шедулер справляется недостаточно хорошо

Проблема стандартного шедьюлера — длинные кванты (обычно 15мс) и отсутствие документированного способа их изменения. Если нужны кванты меньше, остаётся либо недокументированно уменьшать длительность кванта, либо использовать своё планирование.

S>б) есть способ написать свой лучший шедулер?

Написать то можно, но чтобы он был лучше — тут кроется подвох: предположим, нужно переключение через 2мс, мы это обеспечиваем, всё работает. А потом стандартный шедьюлер забирает у нас 60мс . Какой тогда в этом смысл? Всё равно придётся лезть в таймер и подставлять костыли non realtime OS. Если же сделать это, то возникает вопрос: а чем будет самописный шедьюлер лучше чем готовый, но подкрученный? В общем, замкнутый круг .

По поводу примера — многоклиентный сервер (пусть хотя бы чего-то поверх tcp). Пример довольно спорный, и есть разные варианты решения, но ИМХО "оптимизированный" шедьюлер позволил бы значительно экономить ресурсы CPU при переключении между клиентами.

Резюме (ИМХО) такое — сколь бы хорош свой планировщик не был, он не предоставит больше возможностей, чем имеющийся в ОС, поскольку именно последний его органичивает. Свой планироващик может быть удобнее, проще решать задачу, или ещё что-то там, но в ряде случаев он будет похож на человека пытающегося заплыть на водопад .

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>в вытесняющей решение принимает ОС (внешний по отношению к процессу элемент и ему неподконтрольный), а в кооперативной мог бы принимать сам процесс. Если всю Windows со всеми ее программами считать одним большим процессом, то можно заявить, что потоков в обычном понимании слова вообще нет и вытесняющей нет, а просто этот суперпроцесс принимает решение, каким его частям когда выполняться.

Упрощённый алгоритм выбора: "хм, кто тут у нас долше положенного времени отдыхал? нет таких, ну тогда писть пашет [сложная формула с иксом, игреком и... а это что за 3я неизвестная ] знает кто!"

PD>Технические детали (сохранение CONTEXT, перезагрузка CR3 при необходимости и т.д.) здесь роди не играют.
PD>Даже если переключение шло бы на уровне процессора (задачи процессора), это тоже суть дела бы не изменило

Чем дольше будет время переключения контекста выполнения — тем дороже будет стОить многозадачность. Переключение между файберами очень быстрое. Хотя в подовляющем большенстве случаев на сэкономленные копейки ничего не купишь .

PD>А теперь переносим эту идею в мой процесс.

А в моём процессе адгоритм будет уже: "(почесав затылок) ты, ты,... — а можно я? — ...да, и ты, на мясо!".

PD>>>Мой процесс-то, в отличие от ОС, хорошо знает, какой фибер у него чем занимается и в каком у него состоянии дела.

Здравствуйте, Candle645, Вы писали:

C>SwitchToFiber из другого потока приводил к падению всего процесса. Насколько помню — в MSDN где-то сказано, что его можно вызывать только из потока, в котором живет fiber.

You can call SwitchToFiber with the address of a fiber created by a different thread. To do this, you must have the address returned to the other thread when it called CreateFiber and you must use proper synchronization.

Здравствуйте, VladD2, Вы писали:

VD>Мне кажется, что у уважаемого Pavel-а Dvorkin-а одна из главных задач — убить свое время. Он все время интересуется разными тонкими вопросами которые по сути интереса не представляют.

Я тоже интересуюсь всякой такой ерундой. Причина проста — знаю очень мало. Это на Спектруме было понятно зачем каждый байт нужен, а теперь, когда в окружении многих других программ запускается и даже работает моя, первая мысль: "ух как повезло" .