Легкие темы в операционных системах - PullRequest
3 голосов
/ 06 октября 2011

Говорят, что одним из основных преимуществ Node (и предполагаемого витого и др.) По сравнению с более традиционными многопоточными серверами является очень высокая степень параллелизма, обеспечиваемая моделью цикла событий.Основная причина этого заключается в том, что каждый поток занимает много места в памяти, а контексты обмена сравнительно дороги.Когда у вас есть тысячи потоков, сервер проводит большую часть своего времени, переключаясь с потока на поток.

Мой вопрос: почему операционные системы или базовое оборудование не поддерживают гораздо более легкие потоки?Если бы они сделали, вы могли бы решить проблему 10k с простыми потоками?Если они не могут, то почему?

Ответы [ 2 ]

3 голосов
/ 07 октября 2011

Современные операционные системы могут поддерживать выполнение очень большого количества потоков.

В целом, аппаратное обеспечение продолжает работать быстрее (и в последнее время оно стало работать быстрее, что намного удобнее для многопоточности и многопроцессорности, чем для однопоточных циклов событий, т. Е. Увеличено количество ядер, а не увеличена пропускная способность обработки). возможности в одном ядре). Если вы не можете позволить себе накладные расходы сегодня, вы, вероятно, можете позволить себе это завтра.

То, что кооперативные системы многозадачности Twisted (и, по-видимому, Node.js и др.) Предлагает по сравнению с упреждающей многопоточностью (по крайней мере, в форме pthreads), - это простота программирования.

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

Учитывая распространение параллельного оборудования, было бы идеально, если бы многопоточность или многопроцессорность стали проще (и проще правильно ). Актеры, передача сообщений, возможно, даже сети Петри - вот некоторые из решений, которые люди пытались решить эту проблему. Они по-прежнему очень маргинальны по сравнению с основным подходом многопоточности (pthreads). Другой подход - SEDA, который использует несколько потоков для запуска нескольких циклов событий. Это также не завоевало популярность.

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

0 голосов
/ 07 октября 2011

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

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

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

В принципе блокировки (в зависимости от вашей программы) могут быть очень дорогими и могут остановить масштабирование вашей программы за несколько потоков.И вам почти всегда нужно блокировать что-то .

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

...