Comment fonctionne sig_atomic_t ?

sig_atomic_t n'est pas un type de données atomique. C'est juste le type de données que vous êtes autorisé à utiliser dans le contexte d'un gestionnaire de signal, c'est tout. Il vaut donc mieux lire le nom comme "atomique par rapport à la gestion du signal".

Pour garantir la communication avec et depuis un gestionnaire de signaux, une seule des propriétés des types de données atomiques est nécessaire, à savoir le fait que la lecture et la mise à jour verront toujours une valeur cohérente. D'autres types de données (comme peut-être long long ) peut être écrit avec plusieurs instructions assembleur pour la partie inférieure et supérieure, par ex. sig_atomic_t est garanti d'être lu et écrit en une seule fois.

Ainsi, une plate-forme peut choisir n'importe quel type de base entier comme sig_atomic_t pour lequel il peut garantir que volatile sig_atomic_t peut être utilisé en toute sécurité dans les gestionnaires de signaux. De nombreuses plates-formes ont choisi int pour cela, car ils savent que pour eux int est écrit avec une seule instruction.

La dernière norme C, C11, a des types atomiques, mais qui sont une chose complètement différente. Certains d'entre eux (ceux qui sont "sans verrouillage") peuvent également être utilisés dans les gestionnaires de signaux, mais là encore, c'est une histoire complètement différente.

Notez que sig_atomic_t n'est pas sécurisé pour les threads, uniquement pour les signaux asynchrones.

Les atomes impliquent deux types de barrières :

1. Barrière du compilateur. Il s'assure que le compilateur ne réorganise pas les lectures/écritures depuis/vers une variable atomique par rapport aux lectures et écritures vers d'autres variables. C'est ce que volatile le mot-clé le fait.
2. Barrière et visibilité du processeur. Il s'assure que le processeur ne réorganise pas les lectures et les écritures. Sur x86, tous les chargements et magasins vers un stockage aligné de 1,2,4,8 octets sont atomiques. La visibilité garantit que les magasins deviennent visibles pour les autres threads. Encore une fois, sur les processeurs Intel, les magasins sont immédiatement visibles pour les autres threads en raison de la cohérence du cache et du protocole de cohérence de la mémoire MESI. Mais cela pourrait changer à l'avenir. Voir §8.1 OPÉRATIONS ATOMIQUES VERROUILLÉES dans le volume 3A du manuel du développeur de logiciels pour les architectures Intel® 64 et IA-32 pour plus de détails.

Pour un traitement complet du sujet, regardez Atomic Weapons :The C++ Memory Model and Modern Hardware.