Filetage et sécurité des filets en C
Lorsqu’il existe un ensemble commun de données globales à partager entre plusieurs processus threadés, j’ai généralement utilisé un jeton de thread pour protéger la ressource partagée:
Edit – 22/07/15 (incorporer l’ atome comme option viable, selon les commentaires de Jens)
Ma première question est , en C, si j’écris mes routines de manière à garantir que chaque thread accède à un, et un seul élément d’un tableau:
Y a-t-il une raison de penser que l’access asynchrone et simultané à différents indices du même réseau non protégé (comme le montre le diagramme) serait un problème?
Deuxième question: Étant donné qu’un object accessible en tant qu’entité atomique, même en présence d’interruptions asynchrones ( gestion des signaux C99 – 7.14 ), l’utilisation de l’ atome serait-elle une méthode efficace de protection des threads pour une variable par ailleurs non protégée?
Modifier (Précisions pour répondre aux questions dans les commentaires à ce stade):
– Spécificités pour cette application:
– OS cible: Windows 7/8/10
– Compilateur: compatible C99 (ne peut pas utiliser C11, qui inclut le spécificateur de type _ Atomic () )
– H / W: famille Intel i7
Ceci (qui ressemble à une norme C de quelque sorte) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf dit:
NOTE 1 Deux threads d’exécution peuvent mettre à jour et accéder à des emplacements de mémoire distincts sans interférer les uns avec les autres
NOTE 13 Les transformations du compilateur qui introduisent des assignations à un emplacement de mémoire potentiellement partagé qui ne seraient pas modifiées par la machine abstraite sont généralement exclues par cette norme, car une telle assignation pourrait remplacer une autre affectation par un thread différent. ne pas avoir rencontré une course de données. Cela inclut les implémentations d’affectation de membres de données qui écrasent les membres adjacents dans des emplacements de mémoire distincts. Nous excluons aussi généralement le réordonnancement des charges atomiques dans les cas où les atomes en question peuvent être alias, car cela pourrait violer les règles de “séquence visible”.
Si je comprends bien, cela exclurait les préoccupations de Quamrana et vous garantirait que les écritures non protégées sur des emplacements de mémoire séparés ne devraient jamais entraîner un comportement indéfini s’il n’y a pas de problème de données.
En C, cela dépend de votre plate-forme, c’est-à-dire de votre combinaison de compilateur, d’architecture de processeur et de système d’exploitation.
Votre compilateur peut choisir comment utiliser les registres internes et les instructions du processeur pour faire en sorte que le fichier exécutable semble remplir l’intention du programme. Et C peut ne rien savoir sur les threads. Le rôle du système d’exploitation est généralement de fournir une bibliothèque de threads.
Il se peut que certains processeurs exécutent l’écriture sur un élément de votre tableau en lisant un patch de mémoire beaucoup plus grand qu’un seul élément, puis écrasent uniquement les bons bits qui forment un élément dans les registres internes et réécrivent tout le patch. Un programme à thread unique fonctionnerait correctement, mais deux threads ou plus qui s’interrompent mutuellement pourraient provoquer un chaos dans le tableau.
D’un autre côté, ça peut très bien marcher.
Et comme cela a été dit, l’access en lecture seule est toujours parfait.
En outre, Google est votre ami. Il a trouvé cette question de stackoverflow.
Si chaque thread accède à un élément de tableau différent, et uniquement à l’élément auquel il est “affecté”, cela ne devrait pas poser de problème. Les deux scénarios ci-dessus sont essentiellement équivalents, car chaque élément de tableau possède sa propre adresse.