Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
В рантайме языка го происходит нечто похожее: когда в какой-то горутине происходит блокирующийся системный вызов, то все остальные горутины (аналог треда в го) мигрируют на новый ОС тред. То есть, переносят еще не запустившийся код, а не тот код, который в данный момент исполняется.
>> Если же прошло значительное время, а worker всё ещё работает, произведём простую операцию
Поясните пожалуйста, кто и когда это делает, если поток выполнения сейчас внутри worker'а?
Поясните пожалуйста, кто и когда это делает, если поток выполнения сейчас внутри worker'а?
А не могли бы вы придумать несколько сценариев применения данного подхода?
Меня озадачивает самый плохой случай, когда кванта хватает впритык, и поток вызывающий по сути тратит время на функцию, которая могла бы быть в потоке сразу. Плюс мы же не знаем в каком моменте кванта мы вызвали лейзи тред. Т.е. мы можем вызвать и в конце своей порции и в начале.
Я сходу не смог придумать случай, когда это востребовано. Сразу скажу, что думал в контексте геймдева. В прикладных вещах, мне кажется, проблем особых не стоит, и, если уж, например, понадобился быстрый отклик от интерфейса, то все решается по принципу: есть гуй тред, а есть тред расчетов.
Меня озадачивает самый плохой случай, когда кванта хватает впритык, и поток вызывающий по сути тратит время на функцию, которая могла бы быть в потоке сразу. Плюс мы же не знаем в каком моменте кванта мы вызвали лейзи тред. Т.е. мы можем вызвать и в конце своей порции и в начале.
Я сходу не смог придумать случай, когда это востребовано. Сразу скажу, что думал в контексте геймдева. В прикладных вещах, мне кажется, проблем особых не стоит, и, если уж, например, понадобился быстрый отклик от интерфейса, то все решается по принципу: есть гуй тред, а есть тред расчетов.
В самом начале описано: рантайм балансировка числа тредов для обработки запросов. Например, запросов на маршрутизацию пакетов.
Честно говоря не понял, почему одни пакеты могут «настолько» дольше обрабатываться, чем другие на уровне драйвера. А можете еще найти вариантов для прикладников, а не для драйвера, если не вас не затруднит?
PS: А как быть с временем ожидания выхода из функции? Т.е. вызвавший функцию поток спит или нет, пока выполняется запущенная нить?
результат нас может не интересовать, но может интересовать последовательность выполнения фунцкий
PS: А как быть с временем ожидания выхода из функции? Т.е. вызвавший функцию поток спит или нет, пока выполняется запущенная нить?
результат нас может не интересовать, но может интересовать последовательность выполнения фунцкий
http сервер. запустивший спит, пока это функция и не спит, когда она нить. это надо рассматривать семантически как запуск нити, который в удачном случае оптимизируется в вызов функции.
Я понимаю, как работает ваша идея. Я не понимаю применения в сравнении с другими методами.
Как это можно использовать в http-сервере мне тоже не понятно.
Есть сервер, туда идут запросы, они парсятся, результат отдается.
Мы делаем либо на нескольких потоках с примитивами синхронизации, либо плодим кучу потоков на каждый запрос и там выполняем все последовательно.
Ну даже предположить, что вы говорите о варианте «плодить кучу потоков» и, если запрос быстро выполнился, то поток не запускается, то вам все равно надо использовать синхронизацию для ситуации, когда поток запустится, что рождает дополнительную головную боль и именно это я хочу сказать. Вместо двух вариантов, последовательного и параллельного, мы получаем третий последовательно-параллельный.
Одно дело, когда вы точно знаете, что вам надо синхронизироваться, это одна парадигма, и другое дело, когда вы не знаете как дело пойдет, и придется учитывать оба варианта сразу.
Прикладных задач, где это будет лучше я не вижу, поэтому просил примеры, чтобы лучше понять вашу идею.
В общем, я вижу что задаю уже третий вопрос, ответа не увидел ни на один, извините за назойливость, больше тревожить не буду )
Как это можно использовать в http-сервере мне тоже не понятно.
Есть сервер, туда идут запросы, они парсятся, результат отдается.
Мы делаем либо на нескольких потоках с примитивами синхронизации, либо плодим кучу потоков на каждый запрос и там выполняем все последовательно.
Ну даже предположить, что вы говорите о варианте «плодить кучу потоков» и, если запрос быстро выполнился, то поток не запускается, то вам все равно надо использовать синхронизацию для ситуации, когда поток запустится, что рождает дополнительную головную боль и именно это я хочу сказать. Вместо двух вариантов, последовательного и параллельного, мы получаем третий последовательно-параллельный.
Одно дело, когда вы точно знаете, что вам надо синхронизироваться, это одна парадигма, и другое дело, когда вы не знаете как дело пойдет, и придется учитывать оба варианта сразу.
Прикладных задач, где это будет лучше я не вижу, поэтому просил примеры, чтобы лучше понять вашу идею.
В общем, я вижу что задаю уже третий вопрос, ответа не увидел ни на один, извините за назойливость, больше тревожить не буду )
Замнём для ясности. У меня тоже нет какой-то сногсшибательной картины, которая бы явила абсолютную ясность. Разве что данный механизм проще в применении, чем тредпул, и является его заменой.
Может я и слепой, но в статье я не увидел ничего иного, кроме описания событийно-ориентированного программирования, с очередным костылем. Поток событий порождает, с разной интенсивностью, поток исполнителей, существующих в едином контексте, что приводит к необходимости все синхронизировать, я правильно понял? Если правильно, то видится, что в очередной раз «создаются проблемы, и героически решаются». 1) Единый контекст, если нет ограничения наложенных транзакциями, то почему каждой нити не отдать свое псевдо-устройство? (т.е. перенести момент управления устройством на момент синхронизации псевдо устройства и реального) 2) За синхронизацию и разделение контекста не отвечают мониторы(акторы); состояния можно выпилить из нитей отдав их акторам, не блокируя сразу весь контекст для сложного драйвера, но огрести все проблемы множественной блокировки; в решении «Global Lock» получаем бессмысленность разделения на потоки, в решении «обмен сообщениями», получаем задержки и расходы на очередь.
Т.е. требование «одно устройство — одно состояние» делает бессмысленным многозадачность для управления им, каким бы «толстым» оно не было.
Т.е. требование «одно устройство — одно состояние» делает бессмысленным многозадачность для управления им, каким бы «толстым» оно не было.
Что будет если мы передали указатель на локальную переменную куда-то?
Точнее, понятно, что ничего хорошего не будет. И я пока не могу придумать, как решить эту проблему.
Точнее, понятно, что ничего хорошего не будет. И я пока не могу придумать, как решить эту проблему.
В обычной программе указатель на локальную переменную тоже за пределы функции выпускать нельзя. (Можно, но пока она не вернулась.) Ничего нового.
Вот именно, что можно пока она не вернулась. Давайте рассмотрим простой пример:
void print_value(int *value){
printf(«Value: %d», *p);
}
void worker(packet)
{
int bytes_count = ...;
print_value(&bytes_count); // И тут у нас происходит создание нового потока, весь стек копируется в новый поток
// в print_value придет указатель который указывает на значение в «старом» стеке где может быть уже всё что угодно.
}
Беда в том, что даже если копировать в новый поток вызывающую функцию (ту, что вызвала worker()), то это тоже не поможет, потому что у той функции есть свои локальные переменные, которые она могла кому-то отдать.
void print_value(int *value){
printf(«Value: %d», *p);
}
void worker(packet)
{
int bytes_count = ...;
print_value(&bytes_count); // И тут у нас происходит создание нового потока, весь стек копируется в новый поток
// в print_value придет указатель который указывает на значение в «старом» стеке где может быть уже всё что угодно.
}
Беда в том, что даже если копировать в новый поток вызывающую функцию (ту, что вызвала worker()), то это тоже не поможет, потому что у той функции есть свои локальные переменные, которые она могла кому-то отдать.
А ещё проблему с setjmp/longjmp предвижу я. Радует только то, что они никому не нужны.
Это только для сценариев, когда результат функции не важен? Таких очень мало.
Тот же worker(packet) должен сам позаботиться об уничтожении пакета? Т.е. packet (и вообще, любые данные для worker) нельзя создать на стеке вызывающей ф-ции.
И я думаю, затраты на синхронизацию сожрут потенциальный профит. Поскольку мы не знаем, закончится обработка в том же треде, или в другом, придётся писать максимально блокировочно. Например, могут быть хитро заточенные аллокаторы, которые оптимизируют случай, когда malloc и free сделаны в одном потоке, здесь они просядут.
Тот же worker(packet) должен сам позаботиться об уничтожении пакета? Т.е. packet (и вообще, любые данные для worker) нельзя создать на стеке вызывающей ф-ции.
И я думаю, затраты на синхронизацию сожрут потенциальный профит. Поскольку мы не знаем, закончится обработка в том же треде, или в другом, придётся писать максимально блокировочно. Например, могут быть хитро заточенные аллокаторы, которые оптимизируют случай, когда malloc и free сделаны в одном потоке, здесь они просядут.
Если задача может быть решена без потоков, то зачем решать её с потоками, не так ли?
Вот именно, Ваш подход заставляет писать «с потоками». А именно, параметр packet аллоцировать так, как будто он передаётся во владение другому потоку, а это ещё расходы. Обычный подход с пулом потоков гарантирует, что packet будет обработан в текущем потоке, данные можно выделять на стеке, синхронизация не нужна для тех ресурсов, которые мы группировать в потоке пула.
Понятно, что некоторые пакеты обслуживаются быстро, а иные могут потребовать много времени. В такой ситуации хотелось бы иметь механизм, который динамически порождает обслуживающие нити по мере необходимости, и механизм достаточно дешёвый в ситуации, когда лишние нити не нужны
Или просто механизм вида DPC в NT. Может быть, обслуживаемый пулом.
Аналогом DPC в линуксе являются workers + worker threads в качестве пула. Да и подобная штука есть наверное в любой ОС. Другое дело, что это довольно дорого, потому что надо переключать контексты. Автор поста хотел сделать более легковесный вариант, но беда в том, что дизайн языка не сильно расположен к таким штукам.
DPC тоже не бесплатный. Хотя и дешевле треда. Тут любопытно именно то свойство, что решение о формировании треда (или исполнении в рамках тред пула, кстати — что и есть DPC) принимается позже точки потенциального порождения этого треда.
del
По-моему, идея тупиковая. Проблема в том, что если я знаю, что моя функция может быть выполнена параллельно, то я должен быть готов к худшему случаю и написать эту функцию так, как будто она всегда будет выполняться параллельно. Мне нужно будет защитить мьютексами всё, к чему она прикасается. Соответственно, в том случае, когда функция будет исполняться синхронно, она будет делать кучу лишней работы. Если уж делать что-то подобное, то функций должно быть две. Одна для параллельного выполнения, другая — для синхронного. Но тогда нельзя будет начать выполнять функцию синхронно, а затем продолжить параллельно. И значит в этом вообще нет никакого смысла. В общем, я думаю, что это нигде не реализовано неслучайно. Просто нет запроса на такой функционал. Никто не рискнёт доверить системе самой решать, выполнить функцию параллельно или нет.
Это не всегда так. Приведённый пример — исполнение запросов — как раз не предполагает никаких мьютексов. Каждый вызов — новый отдельный запрос. Нитям нечего делить.
Если так, то да. Но это какой-то сферический конь в вакууме. Когда запросам нечего делить, они не имеют побочных эффектов и ничего не возвращают обратно в вызывающую программу, то такие запросы можно ещё лучше соптимизировать — вообще не исполнять. Для вызывающей программы ситуация будет неотличима от очень эффективного исполнения.
обслуживание read-only веб запроса.
Если только для статических данных. Динамические данные могут измениться в процессе при параллельном исполнении. Следовательно, доступ к ним нужно защищать. Но в любом случае для таких специальных задач лучше сразу сделать пул потоков нужного размера и, потратив время на создание потоков лишь один раз, гарантированно обслуживать запросы параллельно, не рассчитывая на милость системы, которая может запустит исполнение параллельно, а может и нет.
Может быть и лучше. Вполне допускаю. Но обоснования — не увидел.
А как можно обосновать столь очевидную вещь? Если какая-то задача лучше решается параллельным исполнением, то очевидно, что наилучшим решением будет сознательно организованная параллельная обработка, полностью исключающая последовательное исполнение. Или это не очевидно?
Нет. Последовательное дешевле, если фактическая нагрузка позволяет.
В Солярисе так (были?) реализованы interrupt threads. Там прерывания обрабатывлись не поверх стека текущего треда, как в традиционном Юниксе, а в специальных пре-аллоцированных тредах. Но вначале, при возникновении прерывания, такой тред не был полноценным, и не был видем планировщику. Только если interrupt thread блокировался, например, на мьютексе, он отлеплялся от ядерного треда, который он прервал, и становился полноценным.
О как интересно! Отличная схема. Особенно при учёте того, что переключение юзер-ядро всё равно переключает стек, и никаких новых накладных расходов не видно. Единственное — что делать с аппаратурой контроллера прерываний. Если обслуживание прерывания полетело в нить, то оно длинное и нужно бы открыть прерывания и разблокировать контроллер прерываний.
Да. Плюс в прерывании можно использовать все обычные синхронизационные примитивы, и нет нужды разбивать обработку на top-half vs. bottom-half. Но Сан в конце концов отказался, кажется, от этой схемы, не помню почему.
В Continuation Passing C (руководство) реализуются зелёные потоки с возможностью миграции на выделенные обычные и обратно:
cpc_detach, cpc_attach The cpc_detach statement detaches the current continuation; the following statements are executed in a dedicated native thread. The opposite operation is performed by cpc_attach, which causes the current continuation to be scheduled by the CPC scheduler.
The cpc_detach and cpc_attach statements can only appear in cpc context.
cpc_detached, cpc_attached The body of a cpc_detached statement is run detached: an implicit cpc_detach is executed upon entering the body, and a cpc_attach is executed upon exiting. The cpc_attached construct is dual: a cpc_attach is executed upon entry, and a cpc_detach is executed upon exit
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Lazy threads: опциональный параллелизм