неатомный в многопоточной среде iOS - PullRequest
0 голосов
/ 12 апреля 2011

Большинство примеров кода iPhone используют атрибут nonatmoc в своих свойствах. Даже те, которые включают [NSThread detachNewThreadSelector: ....]. Однако действительно ли это проблема, если вы не обращаетесь к этим свойствам в отдельном потоке?

Если это так, как вы можете быть уверены, что неатомарные свойства не будут доступны для этого другого в будущем, и в этот момент вы можете забыть, что эти свойства установлены как неатомарные. Это может создавать сложные ошибки.

Помимо установки всех свойств на атомарное, что может быть непрактичным в большом приложении и может привести к появлению новых ошибок, каков наилучший подход в этом случае?

Обратите внимание, что эти вопросы предназначены специально для iOS, а не для Mac в целом.

1 Ответ

1 голос
/ 13 апреля 2011

Во-первых, знайте, что атомарность сама по себе не гарантирует безопасность потоков для вашего класса, она просто генерирует средства доступа, которые устанавливают и получают ваши свойства безопасным для потоков способом. Это тонкое различие. Чтобы создать потокобезопасный код, вам, скорее всего, потребуется сделать гораздо больше, чем просто использовать атомарные методы доступа.

Во-вторых, еще один ключевой момент, который нужно знать, это то, что ваши средства доступа могут быть безопасно вызваны из фоновых или передних потоков независимо от атомарности. Ключевым моментом здесь является то, что они никогда не должны вызываться из двух потоков одновременно. Вы также не можете вызывать сеттер из одного потока, одновременно вызывая геттер из другого и т. Д. То, как вы предотвращаете этот одновременный доступ, зависит от того, какие инструменты вы используете.

Тем не менее, чтобы ответить на ваш вопрос, вы не можете точно знать, что ваши средства доступа не будут доступны в другом потоке в будущем. Вот почему потокобезопасность трудна, а большая часть кода не является поточно-ориентированной. В общем, если вы создаете фреймворк или библиотеку, да, вы можете попытаться сделать ваш поток кода безопасным для целей «защитного программирования», или вы можете оставить его не потокобезопасным. Атомность ваших свойств - лишь малая часть этого. Однако, что бы вы ни выбрали, обязательно запишите это, чтобы пользователи вашей библиотеки не задавались вопросом.

...