>>race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков.
> Раст не умеет в mutex - он не реализуется на расте. Это
> раз. Два - мутекс это не конкурентный доступ. Это костыль, который
> делает из конкурентного неконкурентный.Да-да, точно, и массивов в расте нет, потому что они реализуются на расте.
> К тому же, даже если обернуть ворованный сишный мутекс в фейковое safe,
> то это не будет работать. Конкурентного доступа всё равно не будет.
> Т.е. обращаться ты сможешь только через глобальный мутекс.
Что значит "глобальный мьютекс"? Мьютекс в расте -- это часть типа. Если я пишу Mutex<Vec<f32>>, то это тип, который можно прочитать, например, так: прикрытый мьютексом динамический массив 32-битных флоатов. Где здесь "глобальность мьютекса"?
> Это уже не гарантия раста, а гарантия рантайма.
Эмм, да. А в чём разница? Сколь-нибудь практически полезный конкурентный доступ невозможен без гарантий рантайма.
> И повторю - ссылку можно получить
> только при захвате мутекса, а значит никакого конкурентного доступа нет.
Если ты так говоришь... нуок. И чё, теперь? Нахрен кому нужен твой конкурентный доступ, если он приводит к датарейсам?
> Доступ есть только к мутексу, который вопрованный сишный.
В сях мьютексы уворованны из ассемблера. То есть, некоторые компиляторы могут иметь вендор-специфичные builtin'ы, навроде cmpxchg или там atomic_increment, или что-нибудь типа. Но это не стандарт C, это вендорспецифичная штука. А вообще это делается inline-асмом. C просто не имеет атомарных операций, необходимых для реализации примитивов синхронизации, типа cmpxchg. В расте они, кстати, предоставляются builtin'ами, и часть стандартной библиотеки. https://doc.rust-lang.org/std/sync/atomic/index.html
>>data race в расте элементарно не делается, unsafe нужен, как раз в силу этой самой модели памяти.
> Ещё раз - тебя поимела пропаганда. Никакие data race в расте не
> делаются.
Ну, я как бы и том и говорю, что не делаются. Я не понимаю с чем или с кем ты споришь сейчас. Я о том же говорю, что data race не делаются. Я говорю, что race-condition делаются легко.
> Гонка предполагает шаринг, а наличие шаринга в расте - это
> уб.
Нет, не-Sync шаринг -- это UB. Sync значения вполне можно шарить, и Mutex тому библиотечный пример.
> Давай ещё раз. Раст не даёт возможность шарить данные, а если не
> шарить данные гонок нет. Поэтому попытка написать шаринг на расте продуцирует
> невозможность.
Ты можешь повторять это по десять раз каждый день на сон грядущий. От этого шаринг из раста никуда не денется.
>>И если Arc и Mutex -- это творения стандартной библиотеки и дают простор порассуждать, что это не раст как таковой, а библиотека к нему, то Send и Sync -- это трейты-маркеры типов, прошитые в язык, наряду с другими трейтами-маркерами формирующими модель памяти раста (чтобы это не означало), такими как Clone, Copy, ?Sized.
> Нет, никакая эта херня не имеет никакого отношения к языку. Всё это
> ансейф-хаки не выражаемые на расте. То, что она валяются в stdlib
> - причина одна. Любая скриптуха не способна выразить свою stdlib, поэтому
> эта stdlib всегда пишется на отдельном языке.
Враньё. std лиспа написан на лиспе. std C написан на C. std раста написан на расте. Ну, C и раст наверное нельзя включить в категорию "скриптуха", но лисп прям таким просится туда.
>>Да, ты прикинь, они врут всё про безопасность: массивы тоже в расте не реализуются без unsafe'ов. Ты реально можешь заглянуть в сорцы core::slice и увидеть там как unsafe на unsafe unsafe'ом погоняет: https://doc.rust-lang.org/src/core/slice/mod.rs.html#86
> Зачем мне куда-то заглядывать, если я, в отличии от жертвы пропаганды, понимаю
> модель памяти используемую растом.
А я не понимаю. Я даже не понимаю, что ты имеешь в виду под "моделью памяти". Что за модель памяти? Что-то типа RAM, EM, VAT[1]? Нет, наверное, это всё ж теоретические модели памяти _машины_, а не языка. Или что-то типа этого[2]? Не мог бы ты поделиться ссылкой, на тот теоретический фреймворк, в который позволяет тебе выстроить модель памяти раста?
[1] https://core.ac.uk/download/pdf/18462805.pdf
[2] http://canonical.org/~kragen/memory-models/
Но в любом случае, я скажу тебе одну простую вещь: любая "модель" -- это лишь модель. То есть теория, которая игнорирует существенную часть реальность, для того, чтобы когнитивные дефициты теоретика не мешали бы ему думатьо проблеме. В реальности же, программы на rust не просто имеют конкурентный доступ, они налево и направо им пользуются. Да, они избегают его, потому что раст начинает хмурится. Да, когда они его используют, они стараются обходится const доступом, но это не значит, что нельзя иметь глобальную хеш-табличку символов, где можно конкурентно эти символы искать и откуда их можно конкуретно тягать.
> И, очевидно, могу вывести из неё возможное
> и невозможное.
Нет, из модели ты _по-определению_ модели не можешь вывести всего. Модель по-определению и по-построению рассматривает только некоторые свойства реальности, игнорируя все остальные. Из геометрии Евклида ты не выведешь общую теорию относительности с её пространством-временем. Хотя геометрия Евклида -- это модель пространства, в котором мы живём. Так и из модели памяти языка ты не сможешь вывести все возможные утверждения про язык. Более того, не все утверждения про язык, которые ты сможешь вывести будут применимы.
