Bool Lecture / Écrire Atomic dans l'objectif C?

Je devrais diverger de la réponse acceptée. Désolé. Tandis que l'objectif c ne garantit pas que Bool Properties déclarés non atomique sont en fait atomique, je devrais deviner que le matériel que vous le plus CAREZ ABORDER (tous les appareils iOS et MacOS) Dez des instructions pour effectuer des lectures d'octets et des magasins atomiquement. Donc, à moins que Apple sort avec la route de la route OS fonctionnant sur un microcontrôleur IBM qui a un bus de 5 bits de large pour envoyer 10 bits d'octets sur Vous pouvez également utiliser des bools nonatomiques dans une situation qui appelle des bools atomiques. Le code ne serait pas portable au système d'exploitation de la route, mais si vous le pouvez Sacrifiez l'altéré de votre code nonatomic convient à ce cas d'utilisation. Je suis sûr qu'il y a des individus durcis sur S.O. Cela relèverait du défi du désassemblage de getter bool synthétisé et de setter pour les cas atomiques / nonatomiques pour voir quelle est la différence. Au moins sur le bras.

Votre empocher de ceci est probablement ce

1. Vous pouvez déclarer Bool Properties comme atomique et cela ne vous coûtera pas un centime sur tous les secteurs intrinsèquement de HW iOS et MacOS.
2. Les barrières de mémoire sont orthogonales à atomicité
3. vous ne devriez certainement pas utiliser les propriétés de 4 octets pour stocker des booléens dans Sauf si vous êtes dans la logique fuzzy [très]. C'est idiot et inutile, vous ne voulez pas être un clone d'un programmeur Java, Qui ne peut pas dire un float d'un double, ou du fait-il?
4. Bool Variables (qui ne supportent pas évidemment les décorateurs atomiques / nonatomiques ne serait pas atomique sur certaines architectures de bus étroites objectif c ne pas être utilisé sur de toute façon (microcontrôleurs avec ou sans que certains micro os [très] sont un territoire C & Assembly, je suppose. Ils n'ont généralement pas besoin de la bagage Objc Runtime apporterait)

Que se passe-t-il lorsque deux threads définissent un bool sur Oui "en même temps"? P>

alors sa valeur sera oui code>. Si les threads écrivent la même valeur sur la même position de mémoire, l'emplacement de la mémoire aura cette valeur, que ce soit atomique ou ne joue aucun rôle. Il ne jouerait qu'un rôle que si deux threads écrivent une valeur différente à la même position de mémoire ou si un thread l'écrit tandis que celui-ci la lit. P>

est Bool lecture / écriture atomique dans l'objectif c? p> blockQuote>

C'est si votre matériel est un Macintosh exécutant des macos. bool code> est uint32_t code> sur les systèmes PPC et char code> sur les systèmes Intel et écrire ces types de données est atomique sur leurs systèmes respectifs. P>

Le langage OBJ-C ne fait aucune garantie de ce type. Sur d'autres systèmes, cela dépend de votre compilateur utilisé et de la manière dont bool code> est défini pour cette platine. La plupart des compilateurs (GCC, Clang, ...) garantissent que la rédaction d'une variable de int code> est toujours atomique, que d'autres tailles sont atomiques dépend de la CPU. P>

Notez que Atomic n'est pas le même que le fil-coffre-fort. Écrire un bool code> n'est pas une barrière de mémoire. Le compilateur et la CPU peuvent réorganiser des instructions autour d'un bool code> écrire: p> xxx pré>

Il n'y a aucune garantie que les instructions sont exécutées dans cet ordre. Le fait que b code> est oui code> ne signifie pas que a code> est 10. Le compilateur et la CPU sont libres de mélanger ces trois instructions que vous souhaitez. Ils ne dépendent pas les uns des autres. Les instructions atomiques explicites ainsi que les verrous, les mutiles et les sémaphores sont généralement des barrières de mémoire, cela signifie qu'elles instruissent le compilateur et la CPU de ne pas déplacer les instructions situées avant cette opération au-delà de cela et ne déplacent pas les instructions situées après cette opération avant de le faire (c'est une frontière difficile, Ces instructions peuvent ne pas passer). P>

La cohérence de la cache n'est pas garantie. Même après avoir défini un bool code> sur oui code>, un autre thread peut toujours le voir comme non code> pour une durée limitée. Les opérations de barrière de mémoire sont généralement également des opérations garantissant une synchronisation de cache entre tous les filets / cœurs / coys / processeurs dans le système. P>

et pour ajouter quelque chose de vraiment utile ici aussi, c'est ainsi que vous pouvez assurer la définition d'une valeur booléenne. est atomique et agit comme une barrière de mémoire en 2020 en utilisant C11 qui fonctionnera également dans le code Obj-C: p> xxx pré>

non seulement ce code garantira Atomic écrit au bool (pour Lequel le système choisira un type approprié), il agira également comme une barrière de mémoire (cohérente séquentielle). p>

Pour lire le booléen atomiquement à partir d'un autre fil, vous utiliseriez P>

bool x = atomic_load(&b);