LINUX.ORG.RU

В чем принципиальное отличие тредов и user-level нитей?

 ,


0

2

Если треды запилены на основе оси (я слыхал, так в жабе), тогда понятно, там будут, тормоза, связанные с системными вызовами, и соответствующие ограничения, связанные с ограничениями ос-тредов. А если, они нативные? Это же то же самое, практически, правильно я понимаю? К примеру, если в однопоточном языке есть асинхронность, то мы можем там иметь треды (нити) запиленные с помощью сопрограмм, и разницы не будет, так?

До тех пор пока не заблокируешься на сисколе или ffi-вызове.

KblCb ★★★★★ ()

man вытесняющая многозадачность vs кооперативная многозадачность.

Сопрограммы дадут тебе второе.

x3al ★★★★★ ()

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

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

Ты имеешь в виду явным образом не загрузишь, правильно я понял? Ведь VM однопоточного языка на своем уровне все равно шарит процесс между ядрами?

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

Да что бы она там ни делала — 2 зелёных треда не будут выполняться одновременно (иначе код сломается: он не рассчитан на это). От того, что ни будут скакать по ядрам, будет только вред и лучше сделать pinning.

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

Зависит от RTS. Что-то js подобное так делать не будет, RTS Erlang или Haskell легко раскидают зелёные потоки по OS потокам.

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

Haskell легко

хаскель легко, кто бы в этом сомневался. У него даже репл есть. И он даже иногда не тормозит, а иногда даже не падает. Программы на хаскеле в последнее время стали компилироваться молниеносно, менее 2 часов. Зависимостей почти не тянут, не более пятисот, на прогу, во всяком случае.

Правда от количества ядер это все слабо почему то-зависит. Заговор.

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

Зависит от RTS

Не, в первую очередь от TTD.

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

Круто конечно написано, жаль что только не про этот мир, даже положительные предположения

qnikst ★★★★★ ()

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

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

Конечно не про этот. В этом, чистом мире времени вообще нет.

anonymous ()

Разные реализации имеют разные плюсы и минусы. При чём тут системные вызовы и ОС-потоки, я не знаю. Никаких тормозов у ОС-потоков нет. Максимум — проблема масштабирования на огромное число потоков.

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

Ведь VM однопоточного языка на своем уровне все равно шарит процесс между ядрами?

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

Aswed ★★★★★ ()

А если, они нативные?

«Нативные» потоки это, внезапно, и есть реализация 1x1 на ОС потоках. Делать отличные схемы от 1x1 есть смысл если получится существенно уменьшить оверхед на контекст потока или если ОС не умеет потоки. Во всём остальном софтварные потоки приносят тормоза и кучу прочих недостатоков.

mashina ★★★★★ ()
Ответ на: удаленный комментарий

Эм.. Какого черта в но фичи которым меньше 30 лет?!

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

Делать отличные схемы от 1x1

Там получаются не отличные, а вообще независимые от ОС. Смысл есть хотя бы ради масштабируемости.

Например:

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.

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

Я правильно понял, что ты написал, что во всем остальном программы построенные вокруг select/poll/epoll приносят тормоза и кучу других недостатков?

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

Я правильно понял, что ты написал, что во всем остальном программы построенные вокруг select/poll/epoll приносят тормоза и кучу других недостатков?

Если будешь на них делать потоки в юзерспейсе, до да, правильно понял (т.е. делать свою реализацию libс которая будет заворачивать все блокирующие вызовы через свою асинхронную кухню, управлять контекстами через ~ {get,set}context() и т.д.). Но вообще, конечно, ты всё понял не правильно.

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

ok.. так и запишем, спасибо за развернутый ответ, вопросов больше не имею.

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

Это их selling point, поэтому можно в качестве исключения.

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

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

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

правда сейчас уже развитие ушло дальше

Конечно ушло, ведь хоар обосрался

The version of CSP presented in Hoare's original 1978 paper was essentially a concurrent programming language rather than a process calculus. It had a substantially different syntax than later versions of CSP, did not possess mathematically defined semantics,[10] and was unable to represent unbounded nondeterminism.[11] Programs in the original CSP were written as a parallel composition of a fixed number of sequential processes communicating with each other strictly through synchronous message-passing. In contrast to later versions of CSP, each process was assigned an explicit name, and the source or destination of a message was defined by specifying the name of the intended sending or receiving process

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

В итоге дяденька скатился до Microsoft Research

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

И, кстати, твой хаскелек тоже это говнецо стороной не обошло

Haskell MVars are a rendezvous mechanism for synchronizing threads — это, по-ходу, влияние CSP

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

а все потому, что STM не поддерживает rendezvous ну никак. Впрочем модель актеров подобного примитива тоже не содержит.

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

В модели акторов нет свистелок и перделок. Там есть только один примитив — актор. А суть в том, что первоначальная версия CSP на которую ты указал, оказалась несостоятельна, и хоар ее перекраивал, пользуясь идеями, заимствованными из модели Акторов.

hfucker ()

Угадал автора по заголовку

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

В модели акторов

Чет анонимусы за все твои треды так и не смогли найти эту самую модель. Сам ты ее никому не показал, естественно.

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

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

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

Сам ты ее никому не показал, естественно.

А ты не сомневаешься в существовании Путина? Может тебе пруфец подкинуть?

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