я честно говоря не изучал

но чета я уверен что мутекс первым делом сделает атомарную проверку

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

Wait дольше чем неwait

Если wait делает ось

А невейт это один обмен со сравнением

Wait дольше чем неwait

wait не дольше чем не-wait потому что ты буквально выразил свое пожелание

в случае lock-free ты пошел делать мусорные операции в случае wait ты сказал "мне нужен вот этот ресурс"

кажется, второе чуть более optimization friendly

В случае wait ты начал ждать вместо мусорных операций но скорее всего переключишь контекс

Мы не говорим о реализации wait

Для невейт переключение контекста на многоядерной штуке врятли будет

Мы не говорим о реализации wait

Я чото уверен что wait на винде будет вызовом винапи типа waitforsingleobject

Я чото уверен что wait на винде будет вызовом винапи типа waitforsingleobject

Это не тот вопрос

Принципиально ты можешь вызвать nonnative_wait который будет перечитывать до посинения

Собственно говоря ты это и делаешь

Собственно внутри ты напишешь локфри?

а какой профит от lock free кроме понтов, если не перформанс

нет, lock-free очереь в общем случае МЕНЕЕ производительна

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

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

я плохо понимаю, почему это не может быть реализовано системой на уровне if (wait_on_owned_by_other_instance()) transfer_execution_to_that_instance()

я плохо понимаю, почему это не может быть реализовано системой на уровне if (wait_on_owned_by_other_instance()) transfer_execution_to_that_instance()

потому что локфри вообще к системе не обращается

потому что локфри вообще к системе не обращается

почему это не может быть гарантировано на уровне std::thread?

почему это не может быть гарантировано на уровне std::thread?

потому что тред вообще никакого отношения к этому не имеет

Ну локфри ещё и труднее контролировать осью, почти гарантировано жрется процессорное время ну и говернор соответственно увеличит частоту

потому что тред вообще никакого отношения к этому не имеет

кажется, у mutex-подобных объектов завязки с thread очень жесткие

кажется, у mutex-подобных объектов завязки с thread очень жесткие

вот именно, а в лок фри ни одного такого объекта не используется. бинго

да это Константин опять страдает хуетой которую не понимает

в большинстве случаев (100-102%) это так

Почему? Это замечательное упражнение по программированию

понятно что на всех человеческих системах мьютексы используют фаст лок и хэппи путь там стремительный как один атомик

Почему? Это замечательное упражнение по программированию

я думаю илья имеет в виду практическое применение, не олимпиадное

я думаю илья имеет в виду практическое применение, не олимпиадное

практическое применение упражнения по программированию имеют)

Ну ладно, я уже придумал чудесный пример, зачем нужен lock free - привет, Real Time гарантия

Ну собственно речь про RealTime гарантию

Или как она называется там

Грубо говоря гарантия, что метод будет исполнен в не более, чем _число_ тактов

Ну ладно, я уже придумал чудесный пример, зачем нужен lock free - привет, Real Time гарантия

lock-free не дает real-time гарантий никаких

Грубо говоря гарантия, что метод будет исполнен в не более, чем _число_ тактов

lock-free не дает такой гарантии

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

Эрсултан, параллельные массивы — это такой антипаттерн программирования, специально чтобы так не делать, придумали СТРУКТУРЫ, (они же мини-объекты) Если проходили, то используй массив структур тут.

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

есть кнопка Reply в клиенте, используй ее, без форвардинга

есть кнопка Reply в клиенте, используй ее, без форвардинга

Повторить значит

lock-free не дает real-time гарантий никаких

в случае с очередью дает O(числа параллельных вызовов), видимо

Повторить значит

А еще в @supapro

в случае с очередью дает O(числа параллельных вызовов), видимо

он дает гарантию что _когда-нибудь_ ты сможешь в эту очередь записать, но не гарантирует _когда_

и с чтением такая же фигня

он дает гарантию что _когда-нибудь_ ты сможешь в эту очередь записать, но не гарантирует _когда_

гарантирует, если чтений/записей ограничено

А еще в @supapro

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

гарантирует, если чтений/записей ограничено

если ограничено то и мьютекс тебе такое позволяет

но еще раз - лок-фри не означает реал-тайм

Спасибо огромное

гарантирует, если чтений/записей ограничено

https://stackoverflow.com/a/5680988/6804187 собственно, раз ты мне не веришь - вся польза лок-фри в переизобретении синхронизации минуя системные вызовы)

если ограничено то и мьютекс тебе такое позволяет

в real time у тебя просто нет мьютексов :)

https://stackoverflow.com/a/5680988/6804187 собственно, раз ты мне не веришь - вся польза лок-фри в переизобретении синхронизации минуя системные вызовы)

я тебе верю минимум на порядок больше, чем рандомным челикам на стековерфлоу)

в real time у тебя просто нет мьютексов :)

чойта?

Мьютексы это неявная секвеншнал консистенс с инвалидацией всего кэша

Мьютексы по стандарту обладают acquire семантикой в lock() и release в unlock() Так что никакой seq_cst там нет

кажется, у mutex-подобных объектов завязки с thread очень жесткие

Никаких жёстких связок в стандарте между std::thread и std::mutex мной не обнаружено

нет, lock-free очереь в общем случае МЕНЕЕ производительна

+1. Правильно написанный код с мьютексами как правило производительнее чем lock-free подход. Это не только моё мнение, см CppCon2016, там один из докладчиков говорил что lock-free в большинстве тестов быстрее, потому что сравнивается с убогим решением на мьютексах (с динамической аллокацией в критической секции)

в real time у тебя просто нет мьютексов :)

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

Никаких жёстких связок в стандарте между std::thread и std::mutex мной не обнаружено

Как минимум сразу: если std::mutex дважды lock() одним и тем же thread, то behavior is undefined

Как минимум сразу: если std::mutex дважды lock() одним и тем же thread, то behavior is undefined

для этого есть рекурсивные мьютексы. Костыльность не отменяет, но есть.

для этого есть рекурсивные мьютексы. Костыльность не отменяет, но есть.

я читал cppreference

все там defined, грохнется сразу )

Как минимум сразу: если std::mutex дважды lock() одним и тем же thread, то behavior is undefined

это проблемы стандарта, любят они UB понапихать ради скорости

все там defined, грохнется сразу )

где?

в msvc и gcc точно

Как минимум сразу: если std::mutex дважды lock() одним и тем же thread, то behavior is undefined

У вас то же самое будет с атомарным спинлоком. Получается что ваш cпинлок жёстко связан с std::thread?

У вас то же самое будет с атомарным спинлоком. Получается что ваш cпинлок жёстко связан с std::thread?

Как минимум std::thread что-то гарантирует по поводу работы многопоточной системы

деадлок на спинлоках вообще песня :)

зачастую только кнопка ресет спасает :)

зачастую только кнопка ресет спасает :)

Меня обычно спасает хорошая ОС, у которой действительно есть вытесняющая многозадачность :)

в msvc и gcc точно

что грохнется-то? ты про что вообще?

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

только лайвлок лучше дедлока

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

чувак, ты знаешь что такое UB?

чувак, ты знаешь что такое UB?

наверняка чувак проверил на MSVC и получил std::system_error

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

If lock is called by a thread that already owns the mutex, the behavior is undefined: for example, the program _may_ deadlock

я понимаю что в стандарте UB, а на рабочих системах (linux и винда) это фактически креш

в данный момент времени

я понимаю что в стандарте UB, а на рабочих системах (linux и винда) это фактически креш

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

в данный момент времени

может тебе всё же лучше джаваскрипт?