Здравствуйте, ·, Вы писали:

_>>Значит по тезисам:
_>>1. В данном конкретном примере присвоение global_var как раз будет атомарным. Потому как это int и C++ следит за выравниванием. Как это будет происходить на низком уровне скажем в процессорах Intel можешь глянуть например здесь https://software.intel.com/en-us/articles/software-techniques-for-shared-cache-multi-core-systems в пункте Avoid false sharing.
·>Ты мне пункт Стандарта покажи.

https://en.cppreference.com/w/c/program/sig_atomic_t — там в разделе References можешь их найти. )

_>>4. Насколько я вижу, вся эта дискуссия с тобой свелась к спору о терминологии, что весьма глупо. Лично мне абсолютно всё равно как называть конкретные явления, лишь бы договорить об одном языке для всех. Я могут сформулировать свою мысль в любой терминологии — мой основной тезис вообще не зависит от данного выбора.
·>Терминология в том, что "data race" != "все проблемы многопоточности".

А с этим кто-то спорил? ))) Тут у нас было расхождение только в вопросе считать ли некорректность возникающую например из-за сопрограмм за data race.

_>>5. Ну и наконец тот самый главный тезис: как ни называй описанную проблему, Rust никак от неё не защищает.
·>Rust защищает от data race.

Вне зависимости от верности или не верности этого твоего утверждения, совершенно непонятно какое оно имеет отношение к моему тезису об отсутствие какой-то помощи в решение проблем сопрограмм и т.п. гонок в рамках одного потока. У тебя снова включился режим "несу чушь монологом, не слушая ответов собеседника"?

_>>Ну если ты знаешь CPU, в котором перемещение регистра в ячейку памяти является не атомарным, то с удовольствием послушаю про такой. )))
·>Да, CPU сохраняет регистр атомарно, но это не "равносильно оператору равенства в твоём языке программирования", это вообще лажа. Или пункт Стандарта в студию.

Это равносильно для выровненного (оно так и есть по умолчанию) int'a. Про стандарт уже было выше.

_>>А причём ты тут приплёл барьеры вообще не понятно — они работают только с переупорядочиванием инструкций, никак не влияя на их свойства.
·>Не только. Но и этого достаточно. Без барьеров у тебя этот global_var может так и остаться жить в регистре, например.

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

А та оптимизация, на которую ты намекал, не имеет с этим ничего общего — это исключительно игры компилятора. И отключается она для данной переменной не с помощью барьеров, а помощью ключевого слова volatile.

_>>Ну приведи хоть один контрпример. ))) Любой CPU, в котором это не так.
·>Если этого нет в Стандарте, то это не имеет значения. Хотя... если ты пишешь на C++ как на ассемблере-с-классами, то может и сработать.

Про стандарт см. выше. Так что у нас с CPU, в котором это не так?

_>>На самом деле на многих ещё актуальных аппаратных платформах просто нет специальных атомарных инструкций, как ты думаешь, как там выживают? )))
·>lock-инструкциями, например. Читай std::atomic::is_lock_free() и для чего нужен std::atomic_flag. А шо делать?!..

Какими ещё lock инструкциями, если наш процессор их не умеет? )))

_>>Ну скажем в C++ он просто так невыровненным не окажется — у нас полный контроль за этим. )))
·>Ну т.е. невыровненным он оказаться таки может. ЧТД.

Специально конечно можно — у тебя тут полный контроль (https://en.cppreference.com/w/cpp/language/alignas). Однако по умолчанию у нас всё в порядке. Ну и в случае особой паранойи можешь ещё раз ручками задать для такой важной переменной (которую надо атомарно менять).

_>>·>Там про race condition.
_>>И? О того что ты назовёшь это по другому, у тебя некорректный код вдруг заработает правильно? )))
·>Опятьдвадцатьпять. _Некоторый_ некорректный код, является ошибкой компиляции в rust, когда как в С++ — UB. В этом принципиальное отличие.

Так race condition у нас теперь оказывается даёт ошибку компиляции в Rust? Какие интересные новости... )))

Здравствуйте, alex_public, Вы писали:

_>·>
_>·>Ты похоже не способен воспринимать текст длиннее одного предложения. Теперь ты забыл слова "Safe Rust". Воткнуть Send/Sync как попало куда попало можно только с unsafe.
_>Так, давай раз и навсегда разберёмся что такое unsafe в Rust. Это вовсе не обязательно какой-то FFI или низкоуровневая магия. Это любой код, который нарушает требования BC, но всё же должен быть написан.
Нет. Это код, корректность которого компилятор проверить не может. Если ты используя unsafe напишешь код, нарушающий требования BC, то у тебя не будет safe Rust. Конечно, можно ошибиться, притом где угодно, и никто от этого не защищён, ни пользовательский код, ни компилятор, ни ось, ни железо. Ошибки это баги и их надо срочно исправлять. А если кто-то пишет некорректный код нарочно, то он идиот, ему надо лечиться и не подходить к программированию.

_>И сюда относятся в том числе и все виды контейнеров с доступом из нескольких потоков: и инструменты синхронизации (те самые Mutex, Atomic и т.п.) и различные массивы и всё остальное (можешь посмотреть на часть списка здесь https://doc.rust-lang.org/stable/std/marker/trait.Sync.html в разделе Implementors). Т.е. все подобные инструменты и в стандартной библиотеки языка и в твоём личном коде априори написаны unsafe, просто потому что иначе невозможно. А вот использование этих инструментов в своём коде уже не требует никакого unsafe...
Потому что корректность этих инструментов доказана по-другому, не компилятором. Например, атомарность, мютексы, т.п обеспечиваются соответствующими маш-инструкциями, сисколами и т.п.
Точно так же, например, в языке rust (и даже в C++) нет safe-кода сложения двух целых чисел. Но, я надеюсь ты не будешь спорить, что есть гарантия что "2+2" будет "4", хотя компилятор это не проверяет.

_>В итоге твоя фраза типа "Rust гарантирует отсутствие date race вне unsafe блоков" переводится на практике как "Rust гарантирует отсутствие date race вне участков кода занятых собственно реализацией многопоточного доступа". Подразумевая, что этому коду (где собственно и возможны основные ошибки многопоточности) мы верим на слово.
Нет.

_>... Может быть как корректным, так и нет, в зависимости от реализации MyBox.
Это не корректность данного кода, а корректность всей системы. И зависит не только от MyBox, а от всего окружения. Корректность системы зависит от корректности данного кода и его всех зависимостей, вплоть до железа и законов физики. Данный код же корректен. Я это тебе уже разжевал в первом сообщении.

1. Если в этом коде нет unsafe
2. Если все используемые в этом коде зависимости safe*.
3. Если rust компилятор выдал "ок".
=> то код обладает safety guarantees для данного куска кода.

* — зависимости safe это не значит что они не могут использовать unsafe, ffi, да хоть чёрта лысого, а то что они удовлетворяют требованиям safe.

Здравствуйте, alex_public, Вы писали:

_>>>Значит по тезисам:
_>>>1. В данном конкретном примере присвоение global_var как раз будет атомарным. Потому как это int и C++ следит за выравниванием. Как это будет происходить на низком уровне скажем в процессорах Intel можешь глянуть например здесь https://software.intel.com/en-us/articles/software-techniques-for-shared-cache-multi-core-systems в пункте Avoid false sharing.
_>·>Ты мне пункт Стандарта покажи.
_>https://en.cppreference.com/w/c/program/sig_atomic_t — там в разделе References можешь их найти. )
Мде. Во-первых, ты писал int, а не это. Во-вторых, sig_atomic_t — это atomic в контексте ВНЕЗАПНО signal handler и к многопоточности отношения не имеет. Тут подробности.
И поэтому — твой код некорректный и типичный UB, даже твоя сильная вера не поможет. Чисто по Стандарту.

_>>>4. Насколько я вижу, вся эта дискуссия с тобой свелась к спору о терминологии, что весьма глупо. Лично мне абсолютно всё равно как называть конкретные явления, лишь бы договорить об одном языке для всех. Я могут сформулировать свою мысль в любой терминологии — мой основной тезис вообще не зависит от данного выбора.
_>·>Терминология в том, что "data race" != "все проблемы многопоточности".
_>А с этим кто-то спорил? ))) Тут у нас было расхождение только в вопросе считать ли некорректность возникающую например из-за сопрограмм за data race.
data race про многопоточность. Сопрограммы вообще ортогональны поточности, по сути это сахар (по крайней мере тот пример с await/async).

_>>>5. Ну и наконец тот самый главный тезис: как ни называй описанную проблему, Rust никак от неё не защищает.
_>·>Rust защищает от data race.
_>Вне зависимости от верности или не верности этого твоего утверждения, совершенно непонятно какое оно имеет отношение к моему тезису об отсутствие какой-то помощи в решение проблем сопрограмм и т.п. гонок в рамках одного потока. У тебя снова включился режим "несу чушь монологом, не слушая ответов собеседника"?
data race в одном потоке быть не может. По определению. Я тебе его уже давал.
Гонки в пределах одного потока это вообще не про то. Того же уровня как гонки в цикле for — логические ошибки, а не проблемы возникающие на уровне модели ЯП.

_>>>Ну если ты знаешь CPU, в котором перемещение регистра в ячейку памяти является не атомарным, то с удовольствием послушаю про такой. )))
_>·>Да, CPU сохраняет регистр атомарно, но это не "равносильно оператору равенства в твоём языке программирования", это вообще лажа. Или пункт Стандарта в студию.
_>Это равносильно для выровненного (оно так и есть по умолчанию) int'a. Про стандарт уже было выше.
Как выяснилось, это очередное твоё заблуждение.

_>>>А причём ты тут приплёл барьеры вообще не понятно — они работают только с переупорядочиванием инструкций, никак не влияя на их свойства.
_>·>Не только. Но и этого достаточно. Без барьеров у тебя этот global_var может так и остаться жить в регистре, например.
_>Даа, ну и каша у тебя в голове. Барьеры всего лишь управляют переупорядочиванием инструкций (т.е. если инструкция записи в ячейку памяти была, то она всё равно будет исполнена в какой-то момент), причём действует это как на компилятор, так и на конвейер процессора (т.е. это специальные ассемблерные инструкции).
Инструкции могут не только переупорядочиваться, но и выкидываться. Если оптимизатор решит, что переменная не меняется в данном участке кода, то она может так и жить в регистре или вообще выоптимизировать её в ноль. Или несмотря на то, что в исходном коде перемення изменяется несколько раз, он может выкинуть промежуточные инструкции сохранения в память.
Барьеры предотвращают и это.

_>А та оптимизация, на которую ты намекал, не имеет с этим ничего общего — это исключительно игры компилятора.
Переупорядочивание инструкций это и есть один из видов оптимизации.

_>И отключается она для данной переменной не с помощью барьеров, а помощью ключевого слова volatile.
А ты почитай Cтандарт про volatile:

This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order

И не неси эту чушь больше.

_>>>На самом деле на многих ещё актуальных аппаратных платформах просто нет специальных атомарных инструкций, как ты думаешь, как там выживают? )))
_>·>lock-инструкциями, например. Читай std::atomic::is_lock_free() и для чего нужен std::atomic_flag. А шо делать?!..
Ты опять не удосужился почитать что тебе пишут.

_>Какими ещё lock инструкциями, если наш процессор их не умеет? )))
Это какой процессор не умеет? cli/sti — умеют как минимум все. А если мы говорим о многопроцессорных системах...

_>>>Ну скажем в C++ он просто так невыровненным не окажется — у нас полный контроль за этим. )))
_>·>Ну т.е. невыровненным он оказаться таки может. ЧТД.
_>Специально конечно можно — у тебя тут полный контроль (https://en.cppreference.com/w/cpp/language/alignas). Однако по умолчанию у нас всё в порядке. Ну и в случае особой паранойи можешь ещё раз ручками задать для такой важной переменной (которую надо атомарно менять).
Можно, но зачем, если уж давным давно есть std::atomic

_>>>И? О того что ты назовёшь это по другому, у тебя некорректный код вдруг заработает правильно? )))
_>·>Опятьдвадцатьпять. _Некоторый_ некорректный код, является ошибкой компиляции в rust, когда как в С++ — UB. В этом принципиальное отличие.
_>Так race condition у нас теперь оказывается даёт ошибку компиляции в Rust? Какие интересные новости... )))
Нет. Ты читать умеешь что тебе пишут? "Некоторый" != "race condition".

Здравствуйте, WolfHound, Вы писали:

_>>Или например такой https://en.cppreference.com/w/c/program/sig_atomic_t тип. ))) Да, если что, на всех моих платформах (а у меня код собирается и под сервера и под мобильники и под микроконтроллеры) это просто typedef int.
WH>Но этот тип есть. Может авторы спецификации дураки, что сделали его? А ты один умный?
WH>Или может быть есть платформы, где операции с int'ом не атомарны?
Это он просто как всегда соврал (надеюсь по невежеству, а не просто потому что признаться в сливе боится). sig_atomic_t это для "asynchronous interrupts made by signals" и никакого отношения к многопоточности не имеет. Да и введён он был в лохматые годы, когда в C++ модели многопоточности и в помине не было.

Здравствуйте, WolfHound, Вы писали:

_>>Идём, перечитывать http://rsdn.org/forum/flame.comp/7456381.1

Автор: alex_public
Дата: 28.05.19

. Смотрим на мой код для функции Test и видим там оператор await, который и превращает обычную функцию в сопрограмму. Ещё отмазки будут? )))
WH>Нет. Не превращает.
WH>Он даёт ошибку компиляции.

Эээ что? А ты с какой реализацией сопрограмм то пошёл проверять? С дотнетовской что ли? ))) И откуда по твоему пример на C# возник бы в дискуссии о Rust, C++ и т.п? Для нормальных реализаций сопрограмм (а не как в .net) не требуются какие-то специальные флаги в прототипе функции. Особенно если это stackful реализации (для них await — это просто команда переключения контекста регистров процессора в другой стек и всё.). Но даже если ты захотел попробовать на практике подобный код и именно под C#, то тебе надо было всего лишь поправить его в соответствие с правилами языка ( добавить этот никчемный флаг).

_>>Ууу как всё запущено. Оказывается и постоянные разговоры о мощи метапрограммирования от тебя были только для красного словца. Если ты не представляешь как решить простейшую задачу, которую уже лет 40 как элементарно записывают на убогих макросах C.
WH>Причем тут метапрограммирование вообще?

Ну так ты же писал, что хотя на момент компиляции размер регистра известен, но "на момент написания нам ничего не известно". ))) Тебе подсказать как даже убогое метапрограммирование на макросах C решает эту проблему или уж не надо? )))

WH>У тебя есть операция поведение, которое не определено.

Операция не определена для данных, которые не помещаются целиком в регистр целевого процессора. Для помещающихся в регистр данных всё будет вполне однозначно.

WH>И операция, поведение которой определено.
WH>Иногда их поведение может совпадать.

Ха. Вообще то для чтения/записи atomic переменной используется в точности такая же инструкция, как и для обычного int'a. Можешь посмотреть на реальном коде https://godbolt.org/z/I3lOwe, если так до сих пор сам не понял и мне не веришь. Банально потому, что это эти инструкции атомарные от природы!

И соответственно создают atomic переменные не ради операций типа "чтения" или "записи", а ради операций типа "чтение-изменение-запись". Вот на таких задачах (банальном i++) с одновременным доступом уже требуются специальные атомарные операции (для x86 это большая часть обычных арифметических операций с добавлением префикса lock, блокирующего шину https://godbolt.org/z/1bxe_e).

WH>Но зачем нужно использовать операцию с UB, когда есть операция без UB я так и не понял.

Ты что-то напутал. Я не предлагаю использовать просто int вместо atomic<int> (конечно при условии наличия его на платформе, а то иногда и выбора нет) — это было бы просто глупо.

Я говорил исключительно о том, что параллельная запись двух разных значений в одну переменную типа int никогда не приведёт к каком-то произвольному третьему значению, а всегда будет одно из этих двух, т.к. для int'ов операция атомарная.

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

_>>Или например такой https://en.cppreference.com/w/c/program/sig_atomic_t тип. ))) Да, если что, на всех моих платформах (а у меня код собирается и под сервера и под мобильники и под микроконтроллеры) это просто typedef int.
WH>Но этот тип есть. Может авторы спецификации дураки, что сделали его? А ты один умный?
WH>Или может быть есть платформы, где операции с int'ом не атомарны?

Ну если есть, то просто назови — чего тянуть то?

_>>На всех платформах будет абсолютно одинаковое поведение: атомарные операции записи и чтения регистра в память.
WH>С++ не оперирует понятием регистра.

Причём тут C++, если мы говорим об особенностях аппаратных платформ и твоём утверждение, что на какой-то из них запись регистра в память неатомарна.

Здравствуйте, alex_public, Вы писали:

_>Эээ что? А ты с какой реализацией сопрограмм то пошёл проверять? С дотнетовской что ли? ))) И откуда по твоему пример на C# возник бы в дискуссии о Rust, C++ и т.п?
У тебя спросить надо.

Вот это просто феерично! Я честно не ожидал от тебя такого. Человек, который вроде как разрабатывал язык на базе C#, только лучше, оказывается не представляет как работают сопрограммы! Хотя через них работают важные функции языка (там и yield и async/await). Как ты вообще мог пользоваться этими инструментами с таким пониманием? Как чёрной магией что ли?)))

WH>>У тебя есть операция поведение, которое не определено.
_>Операция не определена для данных, которые не помещаются целиком в регистр целевого процессора. Для помещающихся в регистр данных всё будет вполне однозначно.
Ты и ссылку на стандарт С++ привести можешь?

Как я понимаю, ты решил докопаться до мелочей, чтобы твой слив по основным вопросам был не так заметен?
Re[22]: Безопасность Rust

Автор: WolfHound
Дата: 29.05.19

Re[22]: Безопасность Rust

Автор: WolfHound
Дата: 29.05.19

Здравствуйте, Marty, Вы писали:

M>Ну и где написанный на нём софт? Кроме Paint.NET ничего хорошего я не видел

Ну да, за пределами десктопа софта нет.

Здравствуйте, alex_public, Вы писали:

_>Ха. Вообще то для чтения/записи atomic переменной используется в точности такая же инструкция, как и для обычного int'a. Можешь посмотреть на реальном коде https://godbolt.org/z/I3lOwe, если так до сих пор сам не понял и мне не веришь. Банально потому, что это эти инструкции атомарные от природы!

Ну давай посмотрим вместе:
atomic:

        mov     DWORD PTR v[rip], 1
        mfence

non atomic:

        mov     DWORD PTR v1[rip], 1

Действительно... одной инструкцией меньше, одной больше... Кака разница? В главном-то ты прав!

А ещё давай попробуем другие опции. "x86-64 clang 8.0.0":
atomic:

        mov     eax, 1
        xchg    dword ptr [rip + v], eax

non atomic:

        mov     dword ptr [rip + v1], 1

Или вот "ARM64 gcc 8.2":
atomic:

        stlr    w2, [x1]

non atomic:

        str     w2, [x1]

А особенно прикольно "ARM gcc 8.2"
atomic:

        bl      __sync_synchronize
        mov     r3, #1
        ldr     r4, .L4
        str     r3, [r4]
        bl      __sync_synchronize

non atomic:

        mov     r3, #1
        str     r3, [r4, #4]

Никакой синхронизации, говоришь?

Здравствуйте, Ночной Смотрящий, Вы писали:

M>>Ну и где написанный на нём софт? Кроме Paint.NET ничего хорошего я не видел

НС>Ну да, за пределами десктопа софта нет.

Проблема в том, что Микрософт активно проталкивает JS вместо .Net. Могли бы переписать скайп на дотнете. А переписали на JS. Почему ? Могли бы кучку тулов написать на дотнете, а написали на JS. Почему ?

C>https://www.pcworld.com/article/3213031/best-web-browsers.html?page=2

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

Здравствуйте, Ikemefula, Вы писали:

I>Проблема в том, что Микрософт активно проталкивает JS вместо .Net. Могли бы переписать скайп на дотнете. А переписали на JS. Почему ?

Потому что на момент переписывания Core был сырой.

I> Могли бы кучку тулов написать на дотнете, а написали на JS. Почему ?

Каких тулов? Если ты про VS Code, то причина та же.

Здравствуйте, WolfHound, Вы писали:

_>>Эээ что? А ты с какой реализацией сопрограмм то пошёл проверять? С дотнетовской что ли? ))) И откуда по твоему пример на C# возник бы в дискуссии о Rust, C++ и т.п?
WH>У тебя спросить надо.
WH>

WH>Вот это просто феерично! Я честно не ожидал от тебя такого. Человек, который вроде как разрабатывал язык на базе C#, только лучше, оказывается не представляет как работают сопрограммы! Хотя через них работают важные функции языка (там и yield и async/await). Как ты вообще мог пользоваться этими инструментами с таким пониманием? Как чёрной магией что ли?)))

Это было к тому, что человек хорошо знающий C# (а я раньше именно так думал про тебя), просто физически не сможет написать, что await блокирует поток исполнения.

WH>>>У тебя есть операция поведение, которое не определено.
_>>Операция не определена для данных, которые не помещаются целиком в регистр целевого процессора. Для помещающихся в регистр данных всё будет вполне однозначно.
WH>Ты и ссылку на стандарт С++ привести можешь?

Вообще то это очевидно просто из факта атомарности процессорной команды записи регистра в память. Т.е. тебе просто нужны гарантии того, что оператор присвоения переменной компилировался ровно в одну инструкцию перемещения. А для гарантий этого тебе достаточно чтобы размер данных помещался в регистр и ячейка памяти была выровнена (это и так по умолчанию). Соответственно зная размер регистра на целевой платформе, ты можешь иметь гарантии атомарного чтения/записи для любых данных (не только int, но и намного более сложных) подходящего размера.

Ну а для поддержки кроссплатформенности (чтобы не плодить свои типы через ifdef"ы в зависимости от целевой платформы, хотя я не знаю платформы, где бы он был не int'ом) в C/C++ был введён тип sig_atomic_t, который гарантированно влезает в регистр (собственно это его главное и единственное свойство). Ну и в описание к нему в стандарте можно увидеть как раз гарантии атомарности (естественно не таких как у std::atomic, а просто гарантии атомарного чтения/записи). Но это опять же просто помощник (атомарно будет на любых данных нужного вида) и я его упомянул только потому, что про его атомарность есть слова в стандарте языка.

WH>Как я понимаю, ты решил докопаться до мелочей, чтобы твой слив по основным вопросам был не так заметен?
WH>Re[22]: Безопасность Rust

Автор: WolfHound
Дата: 29.05.19

WH>Re[22]: Безопасность Rust

Автор: WolfHound
Дата: 29.05.19

Так не бесконечное же время у меня для форума. Обычно я отвечаю строго хронологически, но твоё "залётное" сообщение (кстати, как раз в нём не было ни слова про Rust) настолько произвело на меня впечатление, что его обсуждение получило наивысший приоритет. ))) Ну с тобой мы вроде всё выяснили уже... Осталось закончить просвещение товарища точки, который залетел на одном из тех же посторонних вопросов, что и ты, и можно возвращаться к обсуждению Rust'а. Если что, твои сообщения у меня никуда не потерялись (я слежу за форумом из своего почтового клиента, через подписку на темы).

Здравствуйте, alex_public, Вы писали:

_>Это было к тому, что человек хорошо знающий C# (а я раньше именно так думал про тебя), просто физически не сможет написать, что await блокирует поток исполнения.
Читать научись.
Где я там написал про системный поток?
Я написал про остановку исполнения асинхронного кода.

WH>>Ты и ссылку на стандарт С++ привести можешь?
_>Вообще то это очевидно просто из факта атомарности процессорной команды записи регистра в память.
Не можешь.

Здравствуйте, alex_public, Вы писали:

WH>>У тебя спросить надо.
WH>>

WH>>Вот это просто феерично! Я честно не ожидал от тебя такого. Человек, который вроде как разрабатывал язык на базе C#, только лучше, оказывается не представляет как работают сопрограммы! Хотя через них работают важные функции языка (там и yield и async/await). Как ты вообще мог пользоваться этими инструментами с таким пониманием? Как чёрной магией что ли?)))

_>Это было к тому, что человек хорошо знающий C# (а я раньше именно так думал про тебя), просто физически не сможет написать, что await блокирует поток исполнения.

Цитирую WH:

await блокирует исполнение до того момента как process_asyc вернёт результат

Где ты увидел здесь слово "поток" ?

Исполнение — блокирует. Очевидно, что сначала отработает то, что справа от await, await дождется результата, а уже потом присваивание и следующая строчка. Про поток — ни слова. Но ты прочел именно так, как будто речь про поток

Здравствуйте, alex_public, Вы писали:

_>Эээ что? А ты с какой реализацией сопрограмм то пошёл проверять? С дотнетовской что ли? ))) И откуда по твоему пример на C# возник бы в дискуссии о Rust, C++ и т.п? Для нормальных реализаций сопрограмм (а не как в .net) не требуются какие-то специальные флаги в прототипе функции

Дотнетой реализации тоже никаких флагов не требуется.

Здравствуйте, ·, Вы писали:

·>Это он просто как всегда соврал (надеюсь по невежеству, а не просто потому что признаться в сливе боится). sig_atomic_t это для "asynchronous interrupts made by signals" и никакого отношения к многопоточности не имеет. Да и введён он был в лохматые годы, когда в C++ модели многопоточности и в помине не было.

При чём тут C++?
Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.
sig_atomic_t — должен гарантировать атомарность записи в эту переменную, для тех времён было достаточно, чтобы такая переменная была шириной в машинное слово.

Здравствуйте, vdimas, Вы писали:

V>·>Это он просто как всегда соврал (надеюсь по невежеству, а не просто потому что признаться в сливе боится). sig_atomic_t это для "asynchronous interrupts made by signals" и никакого отношения к многопоточности не имеет. Да и введён он был в лохматые годы, когда в C++ модели многопоточности и в помине не было.
V>При чём тут C++?
V>Это артефакты Си/Linux, где Си разрабатывался для целей написания многопоточной операционки.
V>sig_atomic_t — должен гарантировать атомарность записи в эту переменную, для тех времён было достаточно, чтобы такая переменная была шириной в машинное слово.
Понятие многопоточности появилось в языке совсем недавно. Почему ты вообще решил, что sig_atomic_t имеет хоть какое-то отношение к многопоточности?

Здравствуйте, reversecode, Вы писали:

C>>https://www.pcworld.com/article/3213031/best-web-browsers.html?page=2
R>синтетические тесты подлизать фокс ?
R>я скачал хром и фокс
R>открыл 300 табов там и там
R>разных сайтов
R>дождался пока все откроются
R>и посмотрел в процессхакере что тормозила уг
R>дальше отправил ноу в сон
R>и пробудил обратно
R>тормозилла начала еще сильнее тормозить потому что плохо перечитывает свой скриптовый двиг ушедший в сон
Бред....

Здравствуйте, alex_public, Вы писали:

_>Вообще то это очевидно просто из факта атомарности процессорной команды записи регистра в память. Т.е. тебе просто нужны гарантии того, что оператор присвоения переменной компилировался ровно в одну инструкцию перемещения. А для гарантий этого тебе достаточно чтобы размер данных помещался в регистр и ячейка памяти была выровнена (это и так по умолчанию).
Это неверно примерно на половине архитектур, x86 имеет необычно сильную модель. Но даже если запись слова атомарна, то нет никаких гарантий "happens after".

Т.е. код типа:

int valA = 0, valB = 0;

void thread1() {
   valA = 11;
   valB = 12;
}

void thread2() {
   while(true) {
      if (valB == 12) {
         assert(valA == 11);
      }
   }
}

Будет периодически падать с assert'ами, так как thread2 вполне может увидеть значение valB раньше, чем valA.

Здравствуйте, alex_public, Вы писали:

_>На всех платформах будет абсолютно одинаковое поведение: атомарные операции записи и чтения регистра в память. И я всё ещё жду от тебя пример платформы, на которой это не так (ведь это было твоё однозначное утверждение).
Отвечу за WolfHound'а.

См. реализацию методов Load64. На многих архитектурах требуются барьеры/блокировки.

PPC64: https://github.com/golang/go/blob/4a4e05b0b166ef17d62789d7ca6d58aeb846c5d1/src/runtime/internal/atomic/atomic_ppc64x.s#L32
MIPS64: https://github.com/golang/go/blob/4a4e05b0b166ef17d62789d7ca6d58aeb846c5d1/src/runtime/internal/atomic/atomic_mips64x.s#L30

Для сравнения, на x86 этот метод выглядит так: https://github.com/golang/go/blob/4a4e05b0b166ef17d62789d7ca6d58aeb846c5d1/src/runtime/internal/atomic/atomic_amd64x.go