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

BZ>>просто не надо называть нити потоками. и в чём разница между нитями ОС, короутинами буста и потоками эрланга? в частности, причём проблема m:n (речь ведь о том что потоков CPU гораздо меньше чем потоков выполнения программы?) ?

S>У термина thread два устоявшихся перевода на русский язык: нить и поток. Эти термины зачастую используются в одном и том же контексте как взаимозаменяемые, дабы не повторять по 100 раз одно и то же слово.

я думал что нить — это fiber, но fiber оказывается — волокно. ок, с этим ясно. так твой пример который 4 секунды выполнялся — он создавал 100 тыщ полноценных потоков ОС?

S>Короутины (зеленые нити, легковесные потоки)

зелёными потоками принято называть короутины, которые щедулятся рантаймом. можешь зхаглянуть в википедию, там говорится о шуделинге в ВМ, но в ghc например VM нет, так что моё определение более полное. а короутины, соответственно — когда тебе выдали стёк и крутись как хочешь

S>Процессы в Erlang-е -- это более продвинутая разновидность легковесных потоков. ОС про них ничего не знает, представление о них имеет только VM Erlang-а. Но, т.к. Erlang-овская VM сама выделяет кванты времени своим процессам, она имеет возможность вытеснять процесс после определенного количества редукций (т.е. выполненых инструкций VM). Кроме того, стандартная библиотека Erlang-а позволяет Erlang-овскому шедулеру снимать процесс при обращении к блокирующим операциям, передавать саму операцию на соответствующий рабочий поток, а затем поднимать задачу при получении ответа. Т.е. получается своя мини-ОС, которая работает хорошо только, если Erlang-овый код не использует обращения к NIF-ам (т.е. функциям, написанным на C).

собственно, для этого достаточно все обращения к ОС заменять на обёртки, которые умеют кооперироваться с ВМ/рантаймом. преркасно реализуется что в C++ (как раз Asynca это и делает), что в ghc из коробки

S>Проблема M:N возникает, когда у нас много однотипных задач, которые, преимущественно, требуют только процессора. Например, выполняют вычисления. Это означает, что каждая задача, получив свой рабочий квант, будет использовать его полностью, не давая шедулеру снять задачу и отдать процессор кому-то еще. Тут чем быстрее работает задача, чем большие кванты времени ей выдаются, тем лучше.

ты похоже видишь единственный вариант решения этой проблемы — разбить работу на мноджество небольших задач. а можно сделать горажо проще — исользовать короутины, вставить yield в тех же самых местах и при этом сохранить состояние стека. т.е. в эрланге/ghc у нас зелёные треды, а в c++ — короутины, которые отличаются только тем, что надо вручную вставлять yield. всё остальное, включая асинхронный I/O, выглядит точно так же (опять же см. Asynca). поэтому я несогласен с твоей идеей что в С++ надо использовать иную парадигму программирования, неджели в эрланге. всё что нужно сделать — разбавить вычисления yield и ко из просто многопоточного станет выполняемым асинхронно в пуле потоков

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

BZ>>просто не надо называть нити потоками. и в чём разница между нитями ОС, короутинами буста и потоками эрланга? в частности, причём проблема m:n (речь ведь о том что потоков CPU гораздо меньше чем потоков выполнения программы?) ?

S>У термина thread два устоявшихся перевода на русский язык: нить и поток. Эти термины зачастую используются в одном и том же контексте как взаимозаменяемые, дабы не повторять по 100 раз одно и то же слово.

я думал что нить — это fiber, но fiber оказывается — волокно. ок, с этим ясно. так твой пример который 4 секунды выполнялся — он создавал 100 тыщ полноценных потоков ОС?

S>Короутины (зеленые нити, легковесные потоки)

зелёными потоками принято называть короутины, которые шедулятся рантаймом. можешь зхаглянуть в википедию, там говорится о шедулинге в ВМ, но в ghc например VM нет, так что моё определение более полное. а короутины, соответственно — когда тебе выдали стёк и крутись как хочешь

S>Процессы в Erlang-е -- это более продвинутая разновидность легковесных потоков. ОС про них ничего не знает, представление о них имеет только VM Erlang-а. Но, т.к. Erlang-овская VM сама выделяет кванты времени своим процессам, она имеет возможность вытеснять процесс после определенного количества редукций (т.е. выполненых инструкций VM). Кроме того, стандартная библиотека Erlang-а позволяет Erlang-овскому шедулеру снимать процесс при обращении к блокирующим операциям, передавать саму операцию на соответствующий рабочий поток, а затем поднимать задачу при получении ответа. Т.е. получается своя мини-ОС, которая работает хорошо только, если Erlang-овый код не использует обращения к NIF-ам (т.е. функциям, написанным на C).

собственно, для этого достаточно все обращения к ОС заменять на обёртки, которые умеют кооперироваться с ВМ/рантаймом. преркасно реализуется что в C++ (как раз Asynca это и делает), что в ghc из коробки

S>Проблема M:N возникает, когда у нас много однотипных задач, которые, преимущественно, требуют только процессора. Например, выполняют вычисления. Это означает, что каждая задача, получив свой рабочий квант, будет использовать его полностью, не давая шедулеру снять задачу и отдать процессор кому-то еще. Тут чем быстрее работает задача, чем большие кванты времени ей выдаются, тем лучше.

ты похоже видишь единственный вариант решения этой проблемы — разбить работу на мноджество небольших задач. а можно сделать горажо проще — исользовать короутины, вставить yield в тех же самых местах и при этом сохранить состояние стека. т.е. в эрланге/ghc у нас зелёные треды, а в c++ — короутины, которые отличаются только тем, что надо вручную вставлять yield. всё остальное, включая асинхронный I/O, выглядит точно так же (опять же см. Asynca). поэтому я несогласен с твоей идеей что в С++ надо использовать иную парадигму программирования, неджели в эрланге. всё что нужно сделать — разбавить вычисления yield и ко из просто многопоточного станет выполняемым асинхронно в пуле потоков