LINUX.ORG.RU

История изменений

Исправление sf, (текущая версия) :

> Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).

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

Если состояния блокирования нет (100% CPU load), то идеальный случай производительности - это когда на каждом ядре процессора крутится ровно 1 OS thread, а в нем ровно 1 green thread. Идеальная загрузка CPU с минимальным временем переключения контекстов зеленых потоков.

В модели с OS-only threads караулить число активных OS threads надо делать вручную.

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

Апгрейдятся до IO thread только те green threads, что неизбежно блокируются/виснут на долгое время (а избежать сравнительно легко). Остальные продолжают наиболее эффективно жрать CPU/IO.

Единственное вменяемое применение, которое тут предложили, это обертка для сокрытия асинхронного i/o от говнокодера. Но и это выглядит как сомнительный профит.

Каноничным примером проблемы с мультиплексированием IO является пример из 'man select_tut' (второй пример, с сокетами): http://linux.die.net/man/2/select_tut.

Если переписать его на потоки (OS threads) ни красивее, ни быстрее не станет.

До сих пор сомнительный? :]

UPD: уточнил на какие потоки

Исходная версия sf, :

> Быстрее родных работать могут, для I/O костылей требовать не обязательно (хватит только на I/O апгрейдить green thread до OS thread).

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

Если состояния блокирования нет (100% CPU load), то идеальный случай производительности - это когда на каждом ядре процессора крутится ровно 1 OS thread, а в нем ровно 1 green thread. Идеальная загрузка CPU с минимальным временем переключения контекстов зеленых потоков.

В модели с OS-only threads караулить число активных OS threads надо делать вручную.

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

Апгрейдятся до IO thread только те green threads, что неизбежно блокируются/виснут на долгое время (а избежать сравнительно легко). Остальные продолжают наиболее эффективно жрать CPU/IO.

Единственное вменяемое применение, которое тут предложили, это обертка для сокрытия асинхронного i/o от говнокодера. Но и это выглядит как сомнительный профит.

Каноничным примером проблемы с мультиплексированием IO является пример из 'man select_tut' (второй пример, с сокетами): http://linux.die.net/man/2/select_tut.

Если переписать его на потоки ни красивее, ни быстрее не станет.

До сих пор сомнительный? :]