Proteger une structure ou classe d'accès concurrent

Bonjour ,

J'ai une HMI qui communique avec un µC , je récupère de ce µC une trame via port série qui contient environ 20 champs .
Cette HMI sert à piloter une machine avec différent actionneurs, je récupère donc l’état de la machine et des actionneurs
Un thread spécifique s'occupe de récupérer cette trame tout les 500 ms

J'ai donc créer une class RS_COM qui gère la COM entre le µC et le PC
J'ai ensuite créer un class Controleur qui va gérer directement la machine (exemple démarre moteur 3 pendant 5 sec)
Mon HMI va ensuite envoyer ces commandes en fonction des séquence choisi par l'utilisateur .

J'ai mis toute les données de la trame dans une classe MACHINE_STATUS
L'HMI vient donc ensuite lire les propriétés de cette classe à n'importe quel moment .

Comment faire pour être sur que les 2 thread (HMI et refresh) ne vont pas venir lire et écrire la structure en même temps.Et qu'une lecture ne puissent pas être effectuer tant que le rafraichissement complet n'est pas fini


J'ai pour idée de
-mettre une barrière sur l’écriture ( le rafraichissement ) avec un Autoreset event .
-déclare une instance de ma classe Machine_Status en propriété de ma classe controleur et mettre cette même barrière sur le GET de la propriété..

Qu'en pensez vous , je débute et j'ai trouver cette méthode mais je voudrais savoir si il y a mieux ou plus simple..

Merci d'avance pour votre aide !

Le principe de sémaphore me parait ici correspondre à ton besoin, d'autant que c'est un concept rudimentaire de l'informatique embarquée.

De ce que je me rappelle du fonctionnement, l'algo serait de ce type :

Initialisation
Sem = 1

HMI
P(Sem)
Lecture valeurs
V(Sem)

Refresh
P(Sem)
Update valeurs
V(Sem)

P décrémente la valeur de la sémaphore, V l'incrémente.
Quand Sem vaut 0, P est en attente.

Un simple lock ne suffirait-il pas ?

Code:

---

1 2 3 4 5

lock(unObjdeLock) { //faire les choses sur mon objet }

---

salut

J'aurais tendance à utiliser un Lock

Mais aussi faire en sorte d'utiliser un tampon pour la trame.

J'explique.

Le thread qui récupère les informations de la trame peut mettre les données dans une file d'attente. Une fois la trame complètement lu, la donnée peut-etre transférée dans ta structure "partagée" via un lock qui évitera lecture ou écriture par un autre thread durant ce cours temps de transfert des données.

Le plus simple quand on travaille avec des données qui peuvent être modifiées par un autre thread est de travaillé avec des "copies" de structures.

Dans le monde de la 3D, souvent, on utilise des techniques de triples buffering pour eviter que le thread de Rendu (qui doit "pédaler" à fond) est un risque d'avoir des données corrompu par le thread de mise à jour des données (position, orientation,etc...)

enfin, ca serait une approche que j'étudierais !!!

pour plus de performances que le lock : readerwriterlock

voir le : readerWriterLockSlim (conseillé par le msdn car plus rapide et plus simple)