окей, я уточню: "реализация pthreads для linux'а"

Ну так да, говорю же :)

с другой стороны потоки не такие легковесные

Ну так, потому идея n:m тредов и крута. Жалко что нет способа управлять шедулингом потоков своих из юзерспейса нормально

Ну так, потому идея n:m тредов и крута. Жалко что нет способа управлять шедулингом потоков своих из юзерспейса нормально

Ходят слухи, что под виндой как-то можно. Но всем пофигу на форточу, так что да, жаль

Ну так, потому идея n:m тредов и крута. Жалко что нет способа управлять шедулингом потоков своих из юзерспейса нормально

Вам шашечки или ехать? =)

В винде кстати потоки - намного легковеснее

это не полноценные проццесы

В расте были фиберы, жаль их выпилили

слелали бы опциональными

а про macOS есть инфа? как там все устроено?

к сожалению я не вкурсе, думаю похоже на линух

а про macOS есть инфа? как там все устроено?

Там какое-то адище лютое

Там же микроядро

с другой стороны там потомок match

Там же микроядро

хибридо-ядро*

А POSIX вроде в юзерспейсе вообще запилен...

микро сервис микросервисом погоняет

Я слышал, что майкрософт заявляет, что виндовые потоки легковесные, но так и не знаю в чём именно

а что, в линуксе потоки - тяжелые?

у них есть тема GCD для мультипоточности. Говорят что ее нельзя портировать нормально, т.к. у форточек и линухов не хватит возможностей

а что, в линуксе потоки - тяжелые?

читайте выше )

тяжелые = скедулятся через контекст-свитчи и скедулер в ring0

Я слышал, что майкрософт заявляет, что виндовые потоки легковесные, но так и не знаю в чём именно

http://fkn.ktu10.com/?q=node/4865

кратко

Я слышал, что майкрософт заявляет, что виндовые потоки легковесные, но так и не знаю в чём именно

Наверное а сравнении с их процессами?

а что, в линуксе потоки - тяжелые?

По сравнению с виндовыми да - шедулятся в общем порядке, единственное что меньше накладных расходов при создании

Хотя по другим слухам в винде вообще максимально неадекватный шедулинг

Короче винда полна слухов, нихрена непонятно. Все как обычно

тяжелые = скедулятся через контекст-свитчи и скедулер в ring0

А как можно шедулить ещё потоки, если их нужно между разными ядрами перекидывать?

По сравнению с виндовыми да - шедулятся в общем порядке, единственное что меньше накладных расходов при создании

Так а что такого что шедулятсч они также?

Так а что такого что шедулятсч они также?

Наверно что больше переключений контекст - userspace -> kernel с копированием всех структур туда обратно

Мы говорим про нативный потоки, они и должны а кернелспейсе жить

Сори, чет туплю

А как можно шедулить ещё потоки, если их нужно между разными ядрами перекидывать?

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

А как можно шедулить ещё потоки, если их нужно между разными ядрами перекидывать?

Ну тут плюс - раз в линухе можно привязать проццес к ядру, то можно и потоки

папить по ядрам

мапить*

Так а что такого что шедулятсч они также?

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

Как я понимаю "тяжелость" в исходном контексте определяется ресурсами на создание потока, то что они шедулятся ядром берём за основу. И тут вот вопрос, почему потоки тяжелые по сравнению с виндой?

Ну если там просто сравнивают отношение создание процесса/ создание потока. То мб

Ща поищу

В принципе ничего нового - виндовые потоки более легкие потому что более тупые =)

А может дело вовсе в другом - Такие системы, как Windows NT и OS/2, как говорят, имеют «дешёвые» потоки выполнения и «дорогие» процессы. В других операционных системах разница между потоками выполнения и процессами не так велика, за исключением расходов на переключение адресного пространства, которое подразумевает использование буфера ассоциативной трансляции.

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%82%D0%BE%D0%BA_%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F

Может в винде просто процессы настолько тяжелые - что потоки легкие =)

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

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

Средства синхронихации в Win32 есть двух типов: реализованные на уровне пользователя, и на уровне ядра. Первые — это критические секции (critical section), к второму набору относят мьютексы (mutex), события (event) и семафоры (semaphore). Критические секции — легковесный механизм синхронизации, который работает на уровне пользовательского процесса и не использует тяжелых системных вызовов. Он основан на механизме взаимных блокировок или спин локов (spin lock). Поток, который желает обезопасить определенные данные от race conditions вызывает функцию EnterCliticalSection/TryEnterCriticalSection. Если критическая секция свободна — поток занимает ее, если же нет — поток блокируется (т.е. не выполняется и не отъедает процессорное время) до тех пор, пока секция не будет освобождена другим потоком с помощью вызова функции LeaveCriticalSection. Данные функции — атомарные, т.е. вы можете не переживать за целостность ваших данных ;)

https://habrahabr.ru/post/40227/

Ну нинай, единственный сомнительный плюс виндовых потоков - синк на уровне юзер спейс

Ну нинай, единственный сомнительный плюс виндовых потоков - синк на уровне юзер спейс

Ключевой вопрос -- они шедулятся ядром или нет? 99% накладных расходов это переключение контекста же

Итак. Модель 1:1 — самая простая модель. Согласно ее принципам, любой поток созданный в любом процессе управляется напрямую планировщиком ядра ОС. Т.е. имеем отображении 1 к 1 потока пользовательского процесса на поток ядра. Такая модель реализована в Linux начиная с ядра 2.6, а также Windows.

критикал секшнс - это futex?

Ключевой вопрос -- они шедулятся ядром или нет? 99% накладных расходов это переключение контекста же

что линух что винда 1:1

инфа из 2008го =)

Ну всё понятно, легковесность -- маркетинговый ход

Ну исходники закрыты, можно сказать что там ИИ задачи переключает =)

Typical for proprietary world

Ну нинай, единственный сомнительный плюс виндовых потоков - синк на уровне юзер спейс

В Линукс есть фьютексы

ВоошпЕ эта тема была популярны в 2000х думаю, проблема там и осталась, сколько ядер с тех пор утекло

Линуксе же через жопу сделано. Поток - это процесс на самом деле...

нет, поток и процесс уже давно разные вещи

и от форка отличается лишь шаред памятью

ещё общим pid и общим набором сигнал-хендлеров

Эти 2 последних сообщений не противоречат друг другу?

нет

Ну ладно

До какого-то момента pid был разный у потоков одного *процесса*. Потом прикостылили этот tid и сделали чтоб pid одинаковый был. Реализация от этого сильно не изменилась

Там много костылей =)

Непомню точно, попмоему gid процеса это pid * -1

До какого-то момента pid был разный у потоков одного *процесса*. Потом прикостылили этот tid и сделали чтоб pid одинаковый был. Реализация от этого сильно не изменилась

но сейчас то разные

начиная с linux 2.4.0

уже 16 лет как

но сейчас то разные

Ну так не за то и речь.

А о том, что поток и процесс с точки зрения ядра одо и то же

До какого-то момента pid был разный у потоков одного *процесса*. Потом прикостылили этот tid и сделали чтоб pid одинаковый был. Реализация от этого сильно не изменилась

> Реализация от этого сильно не изменилась очень вероятно это влияет на scheduling

> Реализация от этого сильно не изменилась очень вероятно это влияет на scheduling

Кхм, как это может влиять на шедулинг?

может шедулер из этого какие-то выводы делает, хз

ведь я так понимаю что шедулер должен знать что выгоднее переключать потоки (процессы) из одного процесса (группы потоков)

А о том, что поток и процесс с точки зрения ядра одо и то же

на потоки wait() не работает

execve() тушит не только взывающий поток но и весь thread group

сискол tkill() -- как kill() но доставляет сигнал конкретному потоку

нет, поток и процесс уже давно разные вещи

Чем это они отличаются?