Discussion :

[progfou]

Bonjour tout le monde,
J'ai un système sur lequel il y a deux processeurs (enfin, quatre mais je n'en utilise que deux). L'un des deux décode un signal, pendant que l'autre le joue (un son). Le truc, c'est que le décodeur va plus vite que la lecture. J'ai donc trois buffer, qu'il faudrait utiliser alternativement, en utilisant deux compteurs (valeurs stockées en DDR pour avoir une visibilité de ceux-ci pour les deux processeurs). Ma question est là.
Comment je peux coder un algo qui me permettrait de les synchroniser ?
J'ai pensé à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
CPU0:
<div style="margin-left:40px">counter0=0
Décode dans buffer 0
counter0+=1
Décode dans buffer 1
Tant que (counter1<2)
<div style="margin-left:40px">attend</div>FinTantque
counter0+=1
Décode dans buffer 2
Retourne au début</div>-------------------------------------------
CPU1 :
<div style="margin-left:40px">counter1=0
Tant que (counter0<2)
<div style="margin-left:40px">attend</div>FinTantque</div><div style="margin-left:40px">Lis le buffer0
counter1+=1
Lis le buffer1
counter1+=1
Lis le buffer2
Retourne au début</div>

Mais ça ne fonctionne pas.

[Charlemagne]

A priori, pour synchroniser plusieurs processus il faut regarder du coté des "Mutex"

[Sivrît]

Je vois deux problèmes.

Tout d'abord la lecture ne va jamais démarer car chaque processus attend que le compteur de l'autre atteigne 2... avant que son propre compteur ne passe à deux. counter0 va passer à 1 puis on attend et counter0 reste à 0 en attendant que counter0 monte à 2 (ce qui n'arrive pas).

Ensuite les tests sont bien trop incomplets. Il est tout à fait possible pour la lecture de rattraper le décodage ou inversement. Par exemple on attend pour décoder dans le tampon 2 de l'avoir lu, puis on décode super vite 0 et 1 alors qu'ils sont en pleine lecture (il n'y a pas de test pour l'empécher).


Bref pour éviter les trous, comme Charlemagne : vive les mutex.
Personnellement je mettrais un indicateur par tampon pour dire s'il est plein ou pas. Pour décoder, on attend systématiquement que le tampon soit marqué vide (état initial) et on le marque plein APRES l'avoir rempli. Et pour lire on attend qu'il soit plein et après on le marque vide.
Et d'ailleurs en faisant ça je crois que l'on peut se passer de mutex

[progfou]

Effectivement, ce n'est pas compliqué, et ça peut simplifier la chose.
Je ne connais pas les Mutex, mais je me renseigne très vite !

[Matthieu Brucher]

Les mutex sont indispensables dans la programmation concurrentielle comme ici. Les sémaphores sont une espèce un peu plus générale qui peut aussi convenir.

[progfou]

Bon, j'i jeté un oeil aux mutex...
Ce n'est pas super évident, les algos sont nombreux...
Quel est celui qui me conviet le mieux selon vous, car je n'ai que deux tâches...

[Matthieu Brucher]

Le mutex de base, fourni avec ton langage. Tu ne dois pas l'implémenter, seulement utiliser un mutex disponible dans ta bibliothèque standard

[progfou]

Ca m'étonnerait que j'en ai...
C'est une plate-forme embarquée, donc un C dépouillé au maximum.

[Matthieu Brucher]

Ah oui, dans ce cas...
Il te faut utiliser les opérateurs de tests et d'incrémentation "d'un coup", je ne sais plus comment ils s'appellent - je ne m'en rappelle jamais -. En une instruction, ils font test et incrémentation ou test et changement d'état - genre mise d'un drapeau à vrai tout en positionnant les flags selon l'état précédent -. C'est courant comme instruction dans les processeurs.

[Sivrît]

A partir du moment où il y a plusieurs processeurs il devrait y avoir des mutex de dispo. C'est une base et l'os doit en avoir besoin pour gérer tout ça. (Sinon faut les bonnes instructions, limite de l'assembleur et c'est bof).

Miles> J'ai pas fait des tonnes de programmation concurrentielle, mais dans ce cas on ne peut pas se passer de mutex ? Les deux threads ne vont pas se battre pour l'accès aux ressources, tout ce dont ils ont besoin c'est de signaler à l'autre qu'ils ont fini. Donc si on ne fait que tester une valeur sans la modifier et que quand on la modifie c'est pour ne plus y toucher, on ne devrait pas avoir de cas tordus... je crois

[progfou]

A partir du moment où il y a plusieurs processeurs il devrait y avoir des mutex de dispo. C'est une base et l'os doit en avoir besoin pour gérer tout ça. (Sinon faut les bonnes instructions, limite de l'assembleur et c'est bof).

Il n'y a pas d'OS .
C'est de l'embarqué.

Miles> J'ai pas fait des tonnes de programmation concurrentielle, mais dans ce cas on ne peut pas se passer de mutex ? Les deux threads ne vont pas se battre pour l'accès aux ressources, tout ce dont ils ont besoin c'est de signaler à l'autre qu'ils ont fini. Donc si on ne fait que tester une valeur sans la modifier et que quand on la modifie c'est pour ne plus y toucher, on ne devrait pas avoir de cas tordus... je crois

C'est un peu ce à quoi je pensais aussi.

[Charlemagne]

Il te faut utiliser les opérateurs de tests et d'incrémentation "d'un coup", je ne sais plus comment ils s'appellent - je ne m'en rappelle jamais

Ce sont les opérations atomiques: plus pratiques que les mutex, mais en nombre limité (5 sur un pentium)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
= x
x =
x.fetch_and_store(y)
x.fetch_and_add(y)
x.compare_and_swap(y,z)

Les deux threads ne vont pas se battre pour l'accès aux ressources, tout ce dont ils ont besoin c'est de signaler à l'autre qu'ils ont fini. Donc si on ne fait que tester une valeur sans la modifier et que quand on la modifie c'est pour ne plus y toucher, on ne devrait pas avoir de cas tordus... je crois

Je suis d'accord également, ça suffit probablement pour le projet de Progman, mais c'est pas élégant:
-occupation d'un processeur à rien faire
-et si à l'avenir les 2 processus fonctionnaient sur le même processeur, problème?
-ça impose l'utilisation d'une opération atomique, car si les 2 processus chargent la variable en même temps... ou si chaque processus charge la variable dans son cache respectif...

[Matthieu Brucher]

Merci, j'oublie toujours ce nom, atomique, je me rappelle juste que ça commence par un a