Я читал, что неатомные и атомные оба являются небезопасными. но неатомный быстрее, потому что он позволяет более быстрый доступ асинхронно, а атомный - медленнее, он позволяет медленнее осуществлять доступ синхронно.неатомные и атомные потоки небезопасны в объективе c?
Недвижимость atomic Объект C гарантирует, что вы никогда не увидите частичную запись.
То есть, если два потока одновременно записывают значения A и B в одну и ту же переменную X, то одновременное чтение этой же переменной либо даст начальное значение X, либо A или B. С nonatomic, что гарантия не является дольше. Вы можете получить любое значение, включая значения, которые вы никогда явно не писали в эту переменную.
Причина этого заключается в том, что с помощью nonatomic поток чтения может читать переменную, в то время как другой поток находится в середине написания. Итак, часть того, что вы читаете, исходит из старого значения, а другая часть - из нового значения.
Замечание о том, что оба они являются небезопасными, относятся к тому факту, что дополнительные гарантии не предоставляются за пределами этого. Apple's docs привести следующий пример здесь:
XYZPersonРассмотрим объект, в котором как первый, так и последний имена человека изменяются с помощью атомных аксессоров из одного потока. Если другой поток обращается к обоим именам одновременно, атомарные методы getter вернут полные строки (без сбоев), но нет , что эти значения будут правильными именами относительно каждого . Если к моменту обращения к первому имени обращаются, но после изменения последнего имени вы получите несогласованную, несоответствующую пару имен.
Пурист может утверждать, что это определение безопасности потоков является чрезмерно строгим. Технически говоря, atomic уже заботится о гонках и заказе данных, которые вам нужны только с точки зрения дизайнера языка.
С точки зрения приложения-логики, с другой стороны, вышеупомянутый пример с именем-фамилией явно представляет собой ошибку. Для устранения нежелательного поведения требуется дополнительная синхронизация. В этом представлении, специфичном для приложения, класс XYZPerson не является потокобезопасным. Но здесь мы говорим о другом уровне безопасности потоков, чем тот, который имеет дизайнер языка.
Спасибо за разъяснение для атомного и неатомического. Это означает, что неатомный более надежно использовать, например, такие сценарии (например: XYZPerson). но можете ли вы указать, какие могут быть сценарии для атома, где мы должны объявлять свойство с атомарным доступом? – Nitesh
@Nitesh Я никогда не говорил, что неатомное было более надежным.Фактически, с неатомными результатами в примере XYZPerson может быть катастрофическим, что приводит к повреждению данных и/или сбоям. Дело в том, что атомарность - это [не единственное средство] (https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html) для синхронизации многопоточного кода. В качестве примера для использования атомистики используются блокированные структуры данных, которые могут быть полезны в критическом по производительности коду с очень высокой степенью параллелизма. – ComicSansMS
Пожалуйста, укажите, что вы подразумеваете под _thread unsafe_. Atomics действительно дает вам определенные гарантии, в частности они предотвращают чередование частичной записи, что даст значения мусора при одновременной неатомной записи. – ComicSansMS
@ ComicSansMS, потокобезопасное средство, если поток А, выполняющий никакой другой поток, может выполнить в это время до его завершения. С помощью «атомарного» синтезированные методы setter/getter гарантируют, что целое значение всегда возвращается из получателя или задается установщиком независимо от активности сеттера в любом другом потоке. Поэтому, если поток A находится в середине получателя, а поток B вызывает сеттер, фактическое жизнеспособное значение будет возвращено вызывающему абоненту в A. тогда как это будет потокобезопасным? – Nitesh