Re[53]: Безопасность Rust
От: vdimas Россия  
Дата: 07.06.19 15:02
Оценка:
Здравствуйте, ·, Вы писали:

·>Я тебе это уже доказал цитатами.


Ты терял признак атомарности, т.е. твои цитаты были нерелевантны обсуждаемому.


V>>>>Data race — означает одновременные попытки читать и писать некие данные, или одновременные попытки писать.

V>>·>Да. И ведёт к undefined behaviour.
V>>Докажи.
·>

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


Вот как здесь — общий случай, который не относится к частному.
Требовалось доказать, что для атомарных операций чтения/записи это тоже верно.


·>(с) https://www.modernescpp.com/index.php/race-condition-versus-data-race


Учу читать по твоей ссылке, дорого:

Race condition:
A race condition is a situation, in which the result of an operation depends on the interleaving of certain individual operations.

Data race:
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>>Ты споришь с базовой терминологией.

V>>Впрочем, однажды я от тебя подобную жесть уже наблюдал.
·>Я спорю с твоими фантазиями.

Или не понимаешь английского языка.


V>>>>Но может быть и частью алгоритма.

V>>·>Data race не может быть частью корректного алгоритма, т.к. является undefined behaiour и никакие характеристики алгоритма обеспечить не может.
V>>Докажи.
·>

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

·>(с) https://en.cppreference.com/w/cpp/language/memory_model

Докажи верность этого утверждения для атомарно изменяемых переменных.


V>>>>·>Нет. std::atomic гарантирует отсутсвие data race:

V>>>>Только для тех типов, для которых он специализируется с мьютексом унутре.
V>>·>Это твои фантазии.
V>>Докажи.
·>Доказывать твои фантазии? Упаси боже. Ты глупость сказал, ты и доказывай.

Глупости тут говоришь ты.
А моей целью было заставить тебя начать думать.
Начал бы ты думать и обнаружил бы, что для атомарных типов мьютекс в std::atomic не нужен не спроста.
И при этом гарантируется отсутствие гонок.
При том что достоверно известно, что одновременные чтения и запись в переменную идут.
Т.е. прямо согласно определению, это data race.
Или не совсем?


V>>Я хочу сказать, что такой код всегда корректный.

·>Это твои фантазии.

Доказать не в состоянии.
Слился.


V>>Обратное требуется доказать.

·>Корректность кода ты не доказал.

Какого именно?
Покажи строки, которые требуется доказывать?


·>(с) https://en.cppreference.com/w/c/language/atomic


Сравни:
they may be modified by two threads concurrently or modified by one and read by another.
...
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>>·>Ну запрещено в том смысле, что объявлено как UB.

V>>Объявлено как data race, а не UB.
·>data race всегда UB.

Ты уже сравнил определения выше.
В чём отличия?


V>>>>Вызывать собственный обработчик никем не запрещено.

V>>·>Вызывать можно функцию, а не "обработчик".

Можно и обработчик.


·>Что вызывать код с data race не даёт никаких гарантий.


Не пиши на С/С++.
Ну так-то много где еще пишут даже не на С++11, как так?


V>>·>Это не значит, что они могут шарить данные как хотят.

V>>Могут как хотят.
·>Это твои фантазии.

Реальность.
Современные операционки не используют С++, не используют atomic, а операции навроде exchange, cas и fence используют ну очень редко — в основном для реализации примитивов синхронизации высокого уровня или захвата неатомарного ресурса. Еще для постановки в lock-free очередь.
В остальных случаях обходятся без всего этого прекрасно.
Иначе бы тормозили жутко и ты бы первый их поливал за тормознутость.


V>>·>Вообще это два разных механизма сигналы и треды — и требуется очень осторожный подход что можно делать, что нельзя.

V>>В стандарте явно говорится о обработчике сигнала, вызываемого из некоего треда процесса.
·>Тред процесса прерывает своё выполнение и обработчик вызывается ядром в контексте этого треда,

Да, и этого достаточно.
Но тред не просто так прерывает своё исполнение, а в очень важный для абстрактной машины состояния процессора момент.
В какой именно момент, ы?


·>притом сам тред на это время "не работает" по очевидным причинам. Это асинхронность, а не многопоточность. Примерно как async/await.


Это примерно как если тупят не по детски.

Это прерывания.
Ты, походу, не понимаешь, что это.
Тут уже любой студент-первокурсник допёр бы, но ты все тупишь...
RTFM!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.