Est-ce que ce fil est sûr? (données partagées sans mutex/sémaphore)

Il s'agit donc d'une question très particulière:Est-ce que ce fil est sûr? (données partagées sans mutex/sémaphore)

J'utilise un système embarqué avec un seul cœur CPU.

J'ai un thread principal et une interruption. Ils partagent un flottant de 32 bits. L'interruption écrit le flotteur et le thread principal le lit. Les lectures et les écritures ne sont pas synchronisées.

La documentation du processeur indique que la lecture 32 bits est une opération à un cycle.

Ai-je raison de penser que le thread principal ne risque pas de lire une valeur corrompue? Ou y a-t-il d'autres facteurs?

Source

2009-10-08 Johan Kotlinski

Tant que les lectures et les écritures sont des opérations atomiques, cela devrait être bon. Combien de temps une lecture ou une écriture prend est sans importance, bien qu'il semble probable qu'elles sont atomiques si elles ont un cycle.

Source

2009-10-08 20:28:44

Est-ce que l'écriture aurait deux cycles? –

La lecture et l'écriture doivent toutes les deux être atomiques pour que cela fonctionne. Si c'est le cas, vous êtes prêt à partir. S'il y a un problème avec cela, vous pourriez trouver une opération de mémoire où lecture et écriture sont à la fois atomiques, comme un octet. Vous pouvez ensuite l'utiliser comme sémaphore pour restreindre l'accès en lecture/écriture au flottant. –

De même, est-il toujours vrai que les opérations à un cycle sont atomiques sur des cœurs simples? La documentation indique explicitement que test_and_set est atomique. –

Je pense que vous allez bien tant que la routine d'interruption ne lit pas la valeur, puis utilisez la valeur pour calculer une nouvelle valeur à écrire. La documentation indique-t-elle également qu'une écriture prend un cycle?

Si non, alors vous avez besoin de protection.

Source

2009-10-08 20:32:25

Devrait être sûr - si vous pensez que ce n'est pas le cas, vous pouvez désactiver les interruptions avant de lire la valeur, puis l'activer après la lecture. Mais je suis à peu près sûr que vous allez bien -

Source

2009-10-08 20:34:07 Jeff

Les lectures/écritures atomiques peuvent ne pas être la seule considération afin de rendre les opérations sûres pour les threads. Je pense que la réponse dépendrait aussi du modèle de mémoire du système d'exploitation. Vous devez vous assurer qu'une lecture dans votre thread principal obtiendra la dernière valeur écrite par l'interruption.

Source

2009-10-08 20:34:08

Étant donné qu'il ne fonctionne que sur un seul noyau, la mémoire de la CPU ne prendra pas effet - les modèles de mémoire CPU sont les plus importants lorsque différents cœurs peuvent voir les lectures/écritures dans un ordre différent de celui des autres CPU. – Michael

Ne pourrait-il pas être le cas que le code de ré-ordre du compilateur qui pourrait causer un problème sur un seul ordinateur de base? –

Lorsque vous avez dit le modèle de mémoire, je suppose que vous vouliez dire le modèle de mémoire CPU. Le réapprovisionnement du compilateur sera toujours un facteur (très probablement volatile). – Michael

Cela me semble que vous êtes en sécurité. Si la lecture est faite en même temps, personne ne peut écrire sur la moitié des octets. Cela dit, vous devez vous assurer que la valeur est toujours réellement lue par votre thread, au lieu d'être optimisée par le compilateur. Cela peut arriver si le compilateur pense que personne ne pourrait changer la variable de l'extérieur. Le déclarer comme volatile devrait faire l'affaire (si applicable du tout - je ne connais pas votre code).

Source

2009-10-08 20:36:29 eran

Est-ce que ce fil est sûr? (données partagées sans mutex/sémaphore)

Répondre

Questions connexes