Потоки vs события

Я за бан.

Я против.

Открою тайну.
Событие - сигнал.
Поток - инструкции, исполняемые процессором.

ЗЫ:
Твой поток мыслей - какой-то бред.

Я про подходы к разработке приложений, условно, один поток - много неблокирующих задач, либо один поток - одна задача.

Под потоками ты имеешь в виду потоки ОС (threads), я так понимаю. А вот что ты имеешь в виду под событиями, можешь прояснить?

Надо потоки + события. Создаешь в начале потоки что бы паралелиться, и там уже работаешь через асинхронищну.

Имеется ввиду thread-based программирование и event-based программирование. Пример веб сервер, один запрос - один поток, либо у нас один поток, который обрабатывает неблокирующие события.

А третий вариант: много потоков - много задач. Не рассматривается?

Я про подходы к разработке приложений, условно, один поток - много неблокирующих задач, либо один поток - одна задача.

Если задачи тяжелые - один поток на задачу, если легкие - много задач на поток. «Тяжесть» задачи определяешь сравнительно со скоростью переключения контекста - если время переключения на другой поток соразмеримо со временем выполнения задачи, то есть смысл в одном потоке решать несколько задач - в этом случае, время, которые бы было затрачено на переключение контекста, будет потрачено на непосредственно решение задачи. Это в общем, конечно, могут быть нюансы.

Имеется ввиду thread-based программирование и event-based программирование. Пример веб сервер, один запрос - один поток, либо у нас один поток, который обрабатывает неблокирующие события.

Тут нужно рассматривать в контексте конкретной задачи. Потому что может учитываться множество факторов. Вообще лучше использовать тот вариант который проще конкретно тебе. Если задача решается таким вариантом, то на этом и остановиться. Если не решается по какому-то критерию (например кол-во соединений одновременных больше 10000) то подход один поток на задачу не подходит и делаешь уже какой-то пул и диспетчеризацию задач.

А в другом случае может быть тебе нужна повышенная безопасность и тяжелые задачи - там уже вообще один процесс на соединение.

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

Так что вопрос очень обширный.

Надо потоки + события. Создаешь в начале потоки что бы паралелиться, и там уже работаешь через асинхронищну.

Товарищ дело говорит. В общем случае будет симбиоз потоков и диспетчеризации событий.

Имеется ввиду thread-based программирование и event-based программирование.

Одно крокодил другое на север. Оба в вакууме.

Здесь вопрос из серии «одни умные, другие красивые». От задачи зависит и используются оба.

Если имется ввиду нагрузка, то, в общем случае, плодить рой короткоживущих системных (sic!) потоков - плохая идея. Потоки должны жить долго, иначе накладные расходы сожрут весь профит и лучше рассмотреть event-driven (при минимально необходимом кол-ве долгоживущих потоков).

С другой стороны, если это не системные потоки, а green-threads/fibers/ещё как-то обозвано, то, в общем, пофигу - это таже асинхронщина, имитирующая механизм потоков.

Это странное противопоставоение. Ортогональные оне. Одно другого не исключает. Если про обработку подключений вопрос — и их много, ну так выгоднее освоить мультиплексирование через еполл, гугл «c10k», т.к. на каждое подключение поток, как некоторые делают — это наивно. Если подключений стабильно два или три — чего бы нет. Но... никто не мешает это совмещать без пуризма и фанатизма. Главное чтить закон Амдала и понимать, где доп. потоки дадут выигрыш от распараллеливания, а с какого момента их добавлять бессмысленно (это от задачи зависит: на каждый чих потоки создавать бессмысленно точно, особенно в гуе, легко может хватить одного бэкграунд-воркера с очередью).

Событиями ты все процессоры одновременно не нагрузишь. Поэтому для выжимания максимальной производительности — число потоков по количеству процессоров/ядер, каждый поток обрабатывает события.

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

В однопоточном, последовательном обработчике событий если одна из задач заработается дольше обычного, то остальные события будут обработаны позднее обычного.

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

Я за модель акторов.

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

Однопоток пишут только неосиляторы-лохи - это ты верно заметил. Программисты высшего звена всегда пишут многопоток!

Потоки vs события

Это не антонимы.

т.к. на каждое подключение поток, как некоторые делают — это наивно.

Ну так всё же от ядра зависит, что ему потоки стоят.

Программисты высшего звена всегда пишут многопоток!

Да ладно, любой нормальный гуй хотя бы 2 потока имеет: один, причём, с событийным лупом :)

Ну так при считанных подключениях никто огород городить и не будет :)

oops proxy в реверс режиме на солярке жужжал и не парился, пока nginx не принесли. На linux да, кашлял.

«Эффективли» он все равно что однопоточный, т.к. все замыкается на конкуренции за рисовальню. Более того, в qt например крутить события «издревле» можно в другом потоке (но ты не захочешь, т.к. «кросспоатформочки» — то что работало в qt на винде с простым передергиванием processEvents() обломилось в иксах из-за xkb висяков в ожидании события и теперь надо «более другие способы» чем просто прокачка событий). В дотнете нужно было явно Invoke() дергать чтоб избегать странных выстрелов в гуй.

Ээээ... А разве в qt нет своих кроссплатформенных врапперов к потокам? Ну есть же удивительные люди, пишут гуй в питоне в один поток с логикой и жалуются на GIL...

А это не про с нуля на культях написаное, а что-то, со своим мейном и своими потоками, куда надо Qt добавить бесшовно вообще в виде плугина :) Где-то до 5.9 оно получалось на отлично. Сейчас требует просто немного еще телодвижений, т.к. там обнаружили фатальный недостаток при обработке событий на xkb и немножко дополнительно защитились от — т.е. культисты простой способ вывода в чужое GL-окно сами же сломали... а потом «поДчинили» :)

Ну есть же удивительные люди, пишут гуй в питоне в один поток с логикой и жалуются на GIL...

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

Язабан.

Событие - сигнал.

Поток - инструкции, исполняемые процессором

Инструкции — события, процессор — хардварный эвентлуп %)

У anonimous новый аккаунт?

какие преимущества есть у потоков перед событиями

Преимущества в контексте чего?

RTFM «Устройство процессора».

Да ладно, любой нормальный гуй хотя бы 2 потока имеет: один, причём, с событийным лупом :)

Гуеписатели останутся в прошлом через несколько лет и вот почему: «Гугл» вкладывает огромные средства в то, чтобы их поисковик присутствовал на как можно большем количестве вычислительных устройств всего мирового населения, начиная от «умных» часов и пылесосов до телевизоров и автомагнитол. Гуесоздатели же это малые конторы, пытающиеся схватить свой кусок пирога на рынке. При капитализме такой малой конторе переть против «Гугла» просто бесполезно, поэтому программисту вкладываться сейчас в гуеписательство глупо и недальновидно. Я выбираю вэб-технологии, в которых многопоточная обработка пользовательских данных уверенно побеждает убогий однопоток из прошлого.

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

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

А разве не очередь, сигналы, вот это всё????? У меня только wx и tk опыт, в основном wx. Мне понравилось.

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

Какое смелое утверждение... Firefox совсем недавно от потока UI отвязал обработку данных, Chrome регулярно микрофризит на всяком г...е до сих пор... А тут оказывается вон как...

Очередь либо как-то синкается, либо «не блокирующая» :) Иногда, люди не в теме настаивают на применении неблокирующей очереди, скопипащеной с 1024cores, написанной для компилятора 10-й студии... Чтоб девелоперы выкосили из нее велосипедные реализации атомиков, заменив на уже существующие в 2012-й допустим стандартные, чтоб она просто собиралась... И в процессе поняли, «а нахрена Хосе баян?» — внутри коннектора к базе мьютексы и вся «неблокируемость» теряется, т.к. потоки успешно отдыхают на них.

Это у него поп-мифология из разряда «многопоточность обязательно увеличит производительность» :)

RTFM «Устройство процессора»

Что не так?

одно state монада, другое async монада. шо то, шо то - монада. чего тебе ещё надо, собака?

и да, это не ты случайно мерял перл шлакоблокунями, кстати?

а, так понятнее. емнип я синхронизировал очередь, да.