LINUX.ORG.RU

Легкие потоки

 , ,


1

4

Время от времени при перечислении плюсов каких-нибудь языков я вижу следующее: В $ЯЗЫКНЕЙМ легкие зеленые потоки, их можно делать тысячами, и все будет хорошо.

Что это за потоки такие, как они работают, как такое самому сделать - например на C?

популярно

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

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

wakuwaku ★★★★ ()
Последнее исправление: wakuwaku (всего исправлений: 1)
Ответ на: популярно от wakuwaku

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 инструкций вставляет вызов функции для того, чтобы разобраться с очередностью потоков, приоритетами, возможно сменить контекст?

hlebushek ()
Ответ на: комментарий от hlebushek

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от wakuwaku

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?

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

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

wakuwaku ★★★★ ()
Ответ на: комментарий от wakuwaku

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

qnikst ★★★★★ ()
Ответ на: комментарий от hlebushek

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

anonymous ()
Ответ на: комментарий от qnikst

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

yyk ★★★★★ ()
Ответ на: комментарий от qnikst

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

wakuwaku ★★★★ ()
Ответ на: комментарий от wakuwaku

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

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

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

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

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

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

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

wakuwaku ★★★★ ()
Ответ на: комментарий от wakuwaku

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

qnikst ★★★★★ ()
Ответ на: комментарий от hlebushek

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

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

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

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

kike ()
Ответ на: комментарий от wakuwaku

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

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

hateyoufeel ★★★★★ ()
Ответ на: комментарий от hlebushek

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

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

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от wakuwaku

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

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

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

Waterlaz ★★★★ ()
Ответ на: комментарий от hateyoufeel

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

wakuwaku ★★★★ ()
Ответ на: комментарий от Waterlaz

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

wakuwaku ★★★★ ()
Ответ на: комментарий от wakuwaku

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

Waterlaz ★★★★ ()

Я сам только начал втыкать в тему, но вот что пишут про 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.

dkstra ()
Ответ на: комментарий от emulek

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

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

Pavval ★★★★★ ()

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

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

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

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

Macil ★★★★★ ()
Ответ на: комментарий от qnikst

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

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

Macil ★★★★★ ()
Ответ на: комментарий от kike

yield

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

hlebushek ()
Ответ на: комментарий от Macil

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

qnikst ★★★★★ ()
Ответ на: комментарий от hlebushek

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

qnikst ★★★★★ ()
Ответ на: комментарий от hlebushek

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

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

loz ★★★★★ ()
Ответ на: комментарий от hlebushek

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

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

yoghurt ★★★★★ ()
Ответ на: комментарий от hlebushek

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

vertexua ★★★★☆ ()
Ответ на: комментарий от loz

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

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

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

Pavval ★★★★★ ()

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

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

mv ★★★★★ ()
Ответ на: комментарий от mv

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

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

loz ★★★★★ ()
Ответ на: комментарий от mv

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

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

blexey ★★★★ ()
Ответ на: комментарий от blexey

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

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

mv ★★★★★ ()
Ответ на: комментарий от mv

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

makoven ★★★★★ ()
Ответ на: комментарий от nanoolinux

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

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

makoven ★★★★★ ()
Ответ на: комментарий от makoven

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

nagibator ()
Ответ на: комментарий от mv

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

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

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

blexey ★★★★ ()
Ответ на: комментарий от makoven

Го может в некоторой мере, начиная с версии 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.

anonymous ()
Ответ на: комментарий от anonymous

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

makoven ★★★★★ ()
Ответ на: комментарий от makoven

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

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

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

Да.

anonymous ()
Ответ на: комментарий от Macil

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

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

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

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

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

Macil ★★★★★ ()

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

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

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

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.