популярно

https://en.wikipedia.org/wiki/Green_threads

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

In computer programming, green threads are threads that are scheduled by a virtual machine (VM) instead of natively by the underlying operating system.

А почему в операционные системы не встраивают встроенную возможность создавать легковесные потоки?

И как такая штука работает с JIT-компиляцией? Компилятор просто прикидывает, что пусть каждый поток инструкций 100 сделает, и через 100 инструкций вставляет вызов функции для того, чтобы разобраться с очередностью потоков, приоритетами, возможно сменить контекст?

http://c2.com/cgi/wiki?GreenVsNativeThreads

А почему в операционные системы не встраивают встроенную возможность создавать легковесные потоки?

Потому что это фича стандартной библиотеки языка, а вернее рантайма.

Cannot support multi-processor machines. (Green thread apps can run on a multi-CPU machine; they just can't take advantage of the additional CPU(s). HyperThreadedCpus? count as multiple processors for this purpose).

why?

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

OZ, haskell с (n-m маппингом зеленых на нативные нити)?

есть такая возможность. в windows. см. fibers

вроде как jvm тоже сама занимается подобным «маппингом»

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

Насчёт хаскеля ничего не скажу, к тому же это похоже на хак и нужно ещё посмотреть на эффективность в сравнении с реализацией чистых зелёных нитей.

поднял настроение с утра. Давай рассказывай, что там похоже на хак, мне уже даже стало интересно.

Хороший $technology_name, но не практически применимый по большей части.

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

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

Эффективность зависит от конкретной реализации, я практически ничего не знаю о хаскеле. Зелёные нити приносят с собой слишком много неочевидных проблем.

тогда давай обойдемся без фраз «похоже на хак», если нету обоснований?

А почему в операционные системы не встраивают встроенную возможность создавать легковесные потоки?

Что такое встроенная возможность? Если это будет в ядре, то это уже не будут green threads. А если не в ядре, а только в юзерспейсе, то какая особо разница между дефолтно присутствующим API как у винды или ШеленОС и сторонними либами? Принципиально никакой.

Компилятор просто прикидывает, что пусть каждый поток инструкций 100 сделает, и через 100 инструкций вставляет вызов функции для того, чтобы разобраться с очередностью потоков, приоритетами, возможно сменить контекст?

green threads это обычно cooperative schedulling. Потоки либо сами передают управление с помощью yeild, либо шедуллинг происходит при вызове определённых функций, например, работой с IO.

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

Ни мозгов. Если бы ты погуглил, ты бы нашёл, что рантайм GHC очень неплохо работает на вплоть до нескольких десятков CPU. Больше, вероятно, не тестировали.

А почему в операционные системы не встраивают встроенную возможность создавать легковесные потоки?

ЕМНИП, в соляре такая возможность была.

Хороший язык[Haskell], но не практически применимый по большей части.

Эффективность зависит от конкретной реализации, я практически ничего не знаю о хаскеле.

Напиши еще что-нибудь, я тебя прошу.

Фанатики забавные. Гуглил, лет 5 назад. «Неплохо», в сравнении с чем? Этот язык уже подходит для чего-то кроме закрытого энтерпрайза? Можно где-то посмотреть на живой конкурентоспособный продукт?

Отстань, противный, у меня температурка уже несколько дней.

Ну так чай с имбирем и спать, а не зеленые нити =)

Не всё же спать, это слишком скучно. :/

Я сам только начал втыкать в тему, но вот что пишут про Io

Io uses coroutines (user level cooperative threads), instead of preemptive OS level threads to implement concurrency. This avoids the substantial costs (memory, system calls, locking, caching issues, etc) associated with native threads and allows Io to support a very high level of concurrency with thousands of active threads.

http://c2.com/cgi/wiki?GreenVsNativeThreads

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

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

Мне понравилось.

В $ЯЗЫКНЕЙМ легкие зеленые потоки

Зелёные потоки, на самом деле это не очень гут. Для относительно чистых вычислений — оно вполне подойдёт.

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

В GHC, папример, под виндой с этим БОЛЬШАЯ проблема. Вплоть до дедлоков на ровном месте.

Давай рассказывай, что там похоже на хак, мне уже даже стало интересно.

У ГХЦ весь рантайм — один большой хак на C, и пакет base — один большой хак, но уже на хаскеле :P

Держите нас в курсе.

yield

Это что такое? Я знаю только yield, который позволяет по частям генерировать значения какбы для ленивого списка в питоне и некоторых других языках.

Конкретику, пожалуйста, номера багов, строки кода, описание текущих абстракций. Иначе такое мнение не интересно :)

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

А почему в операционные системы не встраивают встроенную возможность создавать легковесные потоки?

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

А почему в операционные системы не встраивают

Встраивают, у винды есть API для этого.

Функция для ручного вызова планировщика потоков

А почему в операционные системы не встраивают встроенную возможность создавать легковесные потоки?

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

Вопрос что считать функционалом ОС - голые сист. вызовы или же юзерспейсную обвязку (libc, WinAPI, etc). Во втором случае ничего не мешает.

У нитей две проблемы: «заклинившую» нить с процессора не сдёрнуть, плюс у каждой нити свой стэк.

Первую проблему можно решить по-крайней мере в Линуксе, используя per-thread таймер. Вторая проблема вам будет cache poison делать. Для тормозных языков, где thunk и прочий подсчёт исполненных инструкций используется, это не так критично, ибо и так уже всё плохо.

У нитей две проблемы: «заклинившую» нить с процессора не сдёрнуть

С ненативным кодом такое можно делать, например в эрланге так.

«заклинившую» нить с процессора не сдёрнуть

Путаешь с джавой.

Путаешь с джавой.

С чего вдруг? Вот крутится сишный код, IO или другую фигню, отлавливаемую зелёным шедуллером, не делает - как его сдёрнуть с процессора?

То есть, рантаймы ерланга и Го не могут приостановить нить в процессе вычислений и перейти к другой нити? Приостанавливаются только на IO-функциях?

Эрланг могёт. Про го не в курсе.

А про что тогда говорит mv?

Вот крутится сишный код, IO или другую фигню, отлавливаемую зелёным шедуллером, не делает

эрланг исполняет свой собственный байткод, а не нативный.

Про сишный код.

Вот крутится сишный код, IO или другую фигню, отлавливаемую зелёным шедуллером, не делает - как его сдёрнуть с процессора?

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

Если возможности сделать это просто и безопасно нет (как в джаве, по крайней мере, от оракла), то такая архитектура ущербна. И городить какую-то свою архитектуру над ней, надеясь на «авось пронесёт», опасно.

Го может в некоторой мере, начиная с версии 1.2:

In prior releases, a goroutine that was looping forever could starve out other goroutines on the same thread, a serious problem when GOMAXPROCS provided only one user thread. In Go 1.2, this is partially addressed: The scheduler is invoked occasionally upon entry to a function. This means that any loop that includes a (non-inlined) function call can be pre-empted, allowing other goroutines to run on the same thread.

Как-то не сильно возбуждает. Хотя бы перекидывать горутины с одного ядра процессора на другое умеет?

Как-то не сильно возбуждает.

Ну не знаю, на практике и такого хватает.

Хотя бы перекидывать горутины с одного ядра процессора на другое умеет?

Да.

рантайм GHC под виндой это вообще большая проблема, можешь на реддите почитать, что Остин писал и благодаря кому 7.8 на винде вообще остался.

и благодаря кому 7.8 на винде вообще остался

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

Проблема действительно серьёзная. Вангую, что если кому-то не «припечёт», то GHC 7.12 на венде тупо не будет и похеру что M$ research.

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

Собственно этот цикл скорее всего и отдает кванты потокам. По другому можно, но тогда идут усложнения с других сторон.

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

Такую модель-стенд можно поднять на любом языке.