Discussion :

[stbeau]

Bonjour

J'ai besoin d'un renseignement concernant les acces au propriété d'un Thread.

consideront le Thread suivant

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
 
type
  PPrgTSK = ^TPrgTSK;
  TPrgTSK = class(TThread)
  private
    FTimeRefresh  : Integer;
  protected
    procedure Execute; override;
  public
    property TimeRefresh: Integer read FTimeRefresh write FTimeRefresh;
    constructor Create;
    destructor Destroy; override;
  end;
 
procedure TPrgTSK.Execute;
begin
    while not Terminated do begin
      if TimeRefresh > 0 then Dec(TimeRefresh,1);
    end;
end;

Dans cette exemple, on y trouve une proprité "TimeResfresh" qui est lu et écrit par ce Thread (procedure Execute). Mon intérrogation se porte sur l'acces a cette propriété depuis l'extérieur.

Faut-il prendre des mesures précises (section critique, mutex ...) pour éviter un accès simultanée et donc un déclenchement d'exception lors d'acces à la propriété "TimeRefresh" depuis un click sur un bouton ou alors depuis un autre Thread sous la forme suivante ?

Code :

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

1
2
3
4
5
 
Var
  Th : TPrgTSK;
...
  Th.TimeRefresh := 200;

Voilà, j'espère avoir été assez claire et vous remércie d'avance.
Stbeau.

[Aka Guymelef]

Bonjour et bienvenue sur Developpez.com

Si j'ai bien compris votre problème vous avez une propriété publique dans le Thread dont la valeur est manipulée par ce dernier mais qui peut également être changée depuis l'extérieur.

Dans ce cas je suggèrerais de définir un accesseur en écriture sur la propriété comme on centralisera l'accès en modification à cette donnée membre ensuite ben ça dépend un peu de comment vous voulez traiter l'accès concurrent. Si c'est juste pour décrémenter correctement une valeur on peut utiliser une section critique mais si c'est plus complexe après il faudrait voir à stocker la valeur ancienne avant de rentrer dans la section critique puis une fois celle-ci ouverte tester si la valeur d'origine est toujours égale à celle actuelle en ce cas faire votre traitement sinon traiter le fait que quelqu'un a modifié la valeur avant vous.

[stbeau]

Je vous remercie pour votre réponse aussi rapide .

Stbeau.

[edam]

la solution est la

[ShaiLeTroll]

Effectivement Edam, le code de SetTickCount donne tout à fait la solution

Juste une question, quel est risque sur la modification d'une propriété entier en accès direct d'avoir un problème d'écriture ? et même si cela arrive, l'écriture de l'entier ce n'est qu'une seule instruction assembleur MOV, les autres instructions n'étant lié qu'à la recherche du pointeur sur le dit entier selon les mécanismes objets de Delphi, en fait, faudrait que la lecture et l'écriture se produise au même moment dans les deux threads différents que chaque thread soit sur un processeur différent ... c'est vrai que c'est bien de le faire, mais un entier c'est quand même moins sensible qu'un pointeur ou une TList ... je m'en rappele dans mes premiers threads, je m'étais même pas posé la question, je partageais la mémoire à tout va (je n'ai appris les threads à l'école que 6 mois après les avoir découvert en apprentissage chez mon boss de l'époque) ... ce n'est que plus tard en découvrant un problème avec une TList que j'ai découvert qu'il fallait protégé le bousin ...

[Franck SORIANO]

C'est ce que j'allais dire... ça sert à rien de protéger une opération atomique.

Juste une remarque quand même :

Code :

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

1
2
3
4
5
6
procedure TPrgTSK.Execute;
begin
    while not Terminated do begin
      if TimeRefresh > 0 then Dec(TimeRefresh,1);
    end;
end;

J'espère que ce n'est qu'un exemple et que tu ne feras pas que ça dans ton thread.
Parce que si TimeRefresh <=0 tu fais une boucle qui va consommer 100% du CPU pour ne rien faire. Dans ce cas, il faudrait au moins faire un petit Sleep pour que windows récupère de la ressource CPU pour les autres threads...

[sjrd]

Si, même les opérations atomiques doivent être protégées, depuis que les multi-processeurs sont arrivés. Cela dit, il y a moyen de protéger une opération atomique plus efficacement qu'avec la lourdeur d'une section critique. Il suffit d'utiliser le modificateur LOCK sur cette instruction.

Moi j'utilise ç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
21
22
23
{*
  Incrémente un compteur de façon thread-safe
  @param I   Compteur à incrémenter
  @return Nouvelle valeur du compteur
*}
function InterlockedIncrement(var I: Integer): Integer;
asm
        MOV     EDX,1
   LOCK XADD    [EAX],EDX
        LEA     EAX,[EDX+1]
end;
 
{*
  Décrémente un compteur de façon thread-safe
  @param I   Compteur à décrémenter
  @return Nouvelle valeur du compteur
*}
function InterlockedDecrement(var I: Integer): Integer;
asm
        MOV     EDX,-1
   LOCK XADD    [EAX],EDX
        LEA     EAX,[EDX-1]
end;

Remarque : il n'est pas possible d'utiliser LOCK sur un MOV. Met le simple accès en lecture ne doit pas être protégé si les modifications sont toutes faites avec LOCK.

[ShaiLeTroll]

Joli méthode, c'est vrai que SysUtils.InterlockedIncrement et SysUtils.InterlockedDecrement, on été prévu par Microsoft (repris par Borland pour Kylix) c'est qu'il y a bien une raison,

Dans SysUtils de Kylix, il y a une variante :

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
function InterlockedIncrement(var I: Integer): Integer;
asm
      MOV   EDX,1
      XCHG  EAX,EDX
 LOCK XADD  [EDX],EAX
      INC   EAX
end;
 
function InterlockedDecrement(var I: Integer): Integer;
asm
      MOV   EDX,-1
      XCHG  EAX,EDX
 LOCK XADD  [EDX],EAX
      DEC   EAX
end;

sous Windows, ces deux fonctions sont des API intégrées dans kernel32

C'est ce que je disais, c'est bien de le faire car les machines multi-core ou multi-proc même avec une faible probabilité peuvent déclencher cela !

... en fait, faudrait que la lecture et l'écriture se produise au même moment dans les deux threads différents que chaque thread soit sur un processeur différent ... ...

[sjrd]

Dans SysUtils de Kylix, il y a une variante :
sous Windows, ces deux fonctions sont des API intégrées dans kernel32

Tiens, j'avais même pas vu que ça existait en standard Je vais pouvoir revoir mon code à l'occasion