Информация об изменениях

Сообщение Re[55]: Безопасность Rust от 08.06.2019 13:36

Изменено 08.06.2019 13:38 vdimas

Re[55]: Безопасность Rust
Здравствуйте, ·, Вы писали:

V>>·>

If a data race occurs, the behavior of the program is undefined.

V>>Вот как здесь — общий случай, который не относится к частному.
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>>·>

If a data race occurs, the behavior of the program is undefined.

V>>Докажи верность этого утверждения для атомарно изменяемых переменных.
·>Я не знаю что такое ты имеешь конкретно "атомарно изменяемых переменных".

Замени на "атомарно изменяемых данных", пофик.


·>Есть типы, объекты у которых есть атомарные операции. Эти типы — 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.

Да ты упорот... )


·>Если есть вопросы, задавай, вместо того чтобы в очередной раз писать некорректное утверждение.


Я-то задаю нужные, но ты скромно их игноришь:

Для атомарных типов и единственной операции?
Не будет, бо это невозможно выразить схемотехнически.
Собсно, потому что нельзя выразить логически, поэтому нельзя схемотехнически.
И ты логически выразить тоже не сможешь.
Мог бы — уже давно бы членораздельно разложил всё по полочкам, что и где не так, вместо кивания на "авторитеты" в лице стандарта, который ты и не читал целиком, а где читал — толком не разобрался всё-равно.


Вот тебе вопрос — вырази, плиз, каким либо образом (можно на пальцах, можно на каракулях) неатомарную операцию записи в память машинного слова.
Напомню, что "машинное слово" означает основную (аппаратную) разрядность регистра процессора, соответствующих внутренних шин данных и как минимум не меньших по ширине (можно больших, кратных) внешних шин данных.
Вперёд!
Re[55]: Безопасность Rust
Здравствуйте, ·, Вы писали:

V>>·>

If a data race occurs, the behavior of the program is undefined.

V>>Вот как здесь — общий случай, который не относится к частному.
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>>·>

If a data race occurs, the behavior of the program is undefined.

V>>Докажи верность этого утверждения для атомарно изменяемых переменных.
·>Я не знаю что такое ты имеешь конкретно "атомарно изменяемых переменных".

Замени на "атомарно изменяемых данных", пофик.


·>Есть типы, объекты у которых есть атомарные операции. Эти типы — 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.

Да ты упорот... )


·>Если есть вопросы, задавай, вместо того чтобы в очередной раз писать некорректное утверждение.


Я-то задаю нужные, но ты скромно их игноришь:

Для атомарных типов и единственной операции?
Не будет, бо это невозможно выразить схемотехнически.
Собсно, потому что нельзя выразить логически, поэтому нельзя схемотехнически.
И ты логически выразить тоже не сможешь.
Мог бы — уже давно бы членораздельно разложил всё по полочкам, что и где не так, вместо кивания на "авторитеты" в лице стандарта, который ты и не читал целиком, а где читал — толком не разобрался всё-равно.


Вот тебе вопрос — вырази, плиз, каким либо образом (можно на пальцах, можно на каракулях) неатомарную операцию записи в память машинного слова.
Напомню, что "машинное слово" означает основную (аппаратную) разрядность регистра процессора, соответствующих внутренних шин данных и как минимум не меньших по ширине (можно больших, кратных) внешних шин данных.
Вперёд!