Сообщение Re[55]: Безопасность Rust от 08.06.2019 13:36
Изменено 08.06.2019 13:38 vdimas
V>>·>
V>>Вот как здесь — общий случай, который не относится к частному.If a data race occurs, the behavior of the program is undefined.
V>>Требовалось доказать, что для атомарных операций чтения/записи это тоже верно.
·>Атомарные операции определены только над атомарными типами. Список атомарных типов приводится явно.
Он приводится для железок в т.ч.
·>Атомарные типы гарантируют отсутствие data race.
Верно.
·>Это я уже тоже многократно цитировал.
Без ума креститься, как известно...
V>>Учу читать по твоей ссылке, дорого:
V>>Race condition:
V>>A race condition is a situation, in which the result of an operation depends on the interleaving of certain individual operations.
V>>Data race:
V>>A data race is a situation, in which at least two threads access a shared variable at the same time. At least on thread tries to modify the variable.
V>>Вопросы?
·>Ты читай до конца и не цитируй фигурно.
А ты не бегай.
Решил поспорить с терминологией — спорь.
Заодно удачки, кстате.
·>Ты заявил "data race может быть причиной race condition." с этим я и спорил. На самом деле ровно наоборот:
·>
A race condition can be the reason for a data race
Ес-но, если уже пошли-поехали по памяти, то возможно что угодно.
Но это уже вторичные свето-шумовые эффекты, неуправляемые.
А мы тут уже неделю обсуждаем сценарий, когда data race провоцируется программистом сознательно.
Так шта, заказнчивай бегать.
Не понимал ты определений до этой подветки? — не понимал.
Вникать в твои виляния "да вы не так меня поняли" желания ноль.
V>>·>
V>>Докажи верность этого утверждения для атомарно изменяемых переменных.If a data race occurs, the behavior of the program is undefined.
·>Я не знаю что такое ты имеешь конкретно "атомарно изменяемых переменных".
Замени на "атомарно изменяемых данных", пофик.
·>Есть типы, объекты у которых есть атомарные операции. Эти типы — std::atomic или _Atomic.
А у других типов нету, что ле?
А что мне мешает ручками объект навроде джавовского Synchronized нарисовать?
Что-то ты совсем решил моск отключить, смотрю...
Сосредоточья, плиз, — стандарт не утверждает, что в природе не существует других атомарных типов и операций над ними.
Он лишь гарантирует, что вот эти — точно атомарны.
Ну и всё, собсно.
·>Стандарт говорит: A program that has two conflicting evaluations has a data race unless ... both conflicting evaluations are atomic operations (see std::atomic)"
·>Следовательно, std::atomic не создают data race. И следовательно их поведение не является undefined.
Лучше бы ты о memory_order говорил, там хоть какой-то смысл был.
Потому что тебя можно тыкать аки неразумного котёнка в спеку любой существующей на свете железки, в которой тоже будет сказано, что обращение к машинному слово атомарно.
И что характерно, блин, я тебя в эту цитату из стандарта тоже тыкал.
V>>Начал бы ты думать и обнаружил бы, что для атомарных типов мьютекс в std::atomic не нужен не спроста.
·>Разберись что такое is_lock_free.
Да ты упорот... )
·>Если есть вопросы, задавай, вместо того чтобы в очередной раз писать некорректное утверждение.
Я-то задаю нужные, но ты скромно их игноришь:
Для атомарных типов и единственной операции?
Не будет, бо это невозможно выразить схемотехнически.
Собсно, потому что нельзя выразить логически, поэтому нельзя схемотехнически.
И ты логически выразить тоже не сможешь.
Мог бы — уже давно бы членораздельно разложил всё по полочкам, что и где не так, вместо кивания на "авторитеты" в лице стандарта, который ты и не читал целиком, а где читал — толком не разобрался всё-равно.
Вот тебе вопрос — вырази, плиз, каким либо образом (можно на пальцах, можно на каракулях) неатомарную операцию записи в память машинного слова.
Напомню, что "машинное слово" означает основную (аппаратную) разрядность регистра процессора, соответствующих внутренних шин данных и как минимум не меньших по ширине (можно больших, кратных) внешних шин данных.
Вперёд!
V>>·>
V>>Вот как здесь — общий случай, который не относится к частному.If a data race occurs, the behavior of the program is undefined.
V>>Требовалось доказать, что для атомарных операций чтения/записи это тоже верно.
·>Атомарные операции определены только над атомарными типами. Список атомарных типов приводится явно.
Он приводится для железок в т.ч.
·>Атомарные типы гарантируют отсутствие data race.
Верно.
·>Это я уже тоже многократно цитировал.
Без ума креститься, как известно...
V>>Учу читать по твоей ссылке, дорого:
V>>Race condition:
V>>A race condition is a situation, in which the result of an operation depends on the interleaving of certain individual operations.
V>>Data race:
V>>A data race is a situation, in which at least two threads access a shared variable at the same time. At least on thread tries to modify the variable.
V>>Вопросы?
·>Ты читай до конца и не цитируй фигурно.
А ты не бегай.
Решил поспорить с терминологией — спорь.
Заодно удачки, кстате.
·>Ты заявил "data race может быть причиной race condition." с этим я и спорил. На самом деле ровно наоборот:
·>
A race condition can be the reason for a data race
Ес-но, если уже пошли-поехали по памяти, то возможно что угодно.
Но это уже вторичные свето-шумовые эффекты, неуправляемые. И не факт что будут именно они, хотя могут и быть.
Но мы уже неделю обсуждаем другой сценарий — когда data race провоцируется программистом сознательно.
Так шта, заказнчивай бегать.
Не понимал ты определений до этой подветки? — не понимал.
Вникать в твои виляния "да вы не так меня поняли" желания ноль.
V>>·>
V>>Докажи верность этого утверждения для атомарно изменяемых переменных.If a data race occurs, the behavior of the program is undefined.
·>Я не знаю что такое ты имеешь конкретно "атомарно изменяемых переменных".
Замени на "атомарно изменяемых данных", пофик.
·>Есть типы, объекты у которых есть атомарные операции. Эти типы — std::atomic или _Atomic.
А у других типов нету, что ле?
А что мне мешает ручками объект навроде джавовского Synchronized нарисовать?
Что-то ты совсем решил моск отключить, смотрю...
Сосредоточья, плиз, — стандарт не утверждает, что в природе не существует других атомарных типов и операций над ними.
Он лишь гарантирует, что вот эти — точно атомарны.
Ну и всё, собсно.
·>Стандарт говорит: A program that has two conflicting evaluations has a data race unless ... both conflicting evaluations are atomic operations (see std::atomic)"
·>Следовательно, std::atomic не создают data race. И следовательно их поведение не является undefined.
Лучше бы ты о memory_order говорил, там хоть какой-то смысл был.
Потому что тебя можно тыкать аки неразумного котёнка в спеку любой существующей на свете железки, в которой тоже будет сказано, что обращение к машинному слово атомарно.
И что характерно, блин, я тебя в эту цитату из стандарта тоже тыкал.
V>>Начал бы ты думать и обнаружил бы, что для атомарных типов мьютекс в std::atomic не нужен не спроста.
·>Разберись что такое is_lock_free.
Да ты упорот... )
·>Если есть вопросы, задавай, вместо того чтобы в очередной раз писать некорректное утверждение.
Я-то задаю нужные, но ты скромно их игноришь:
Для атомарных типов и единственной операции?
Не будет, бо это невозможно выразить схемотехнически.
Собсно, потому что нельзя выразить логически, поэтому нельзя схемотехнически.
И ты логически выразить тоже не сможешь.
Мог бы — уже давно бы членораздельно разложил всё по полочкам, что и где не так, вместо кивания на "авторитеты" в лице стандарта, который ты и не читал целиком, а где читал — толком не разобрался всё-равно.
Вот тебе вопрос — вырази, плиз, каким либо образом (можно на пальцах, можно на каракулях) неатомарную операцию записи в память машинного слова.
Напомню, что "машинное слово" означает основную (аппаратную) разрядность регистра процессора, соответствующих внутренних шин данных и как минимум не меньших по ширине (можно больших, кратных) внешних шин данных.
Вперёд!