Discussion :

[der§en]

Bonjour,

A votre avis, dans un setter, est-il risqué de faire comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
procedure TStefThread.SetGroupage(Value: Boolean);
begin
  if FGroupage <> Value then
  begin
    FLogLock.Enter;
    try
      FGroupage := Value;
    finally
      FLogLock.Leave;
    end;
  end;
end;

Ou plutôt, impérativement, comme cela :

Code :

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

1
2
3
4
5
6
7
8
9
10
procedure TStefThread.SetGroupage(Value: Boolean);
begin
  FLogLock.Enter;
  try
    if FGroupage <> Value then
      FGroupage := Value;
  finally
    FLogLock.Leave;
  end;
end;

Est-il judicieux de "consommer" un TCriticalSection, si le test "FGroupage <> Value" renvoi FALSE ?

[sergio_is_back]

La question n'est pas de "consommer" ou pas un TCriticalSection (qui n'est qu'un simple verrou en réalité)
La question c'est à quoi sert ce test ?
Si Value=FGroupage alors la valeur ne change pas !!! Du coup quel est l'intérêt de ce test dans les deux cas ?

[Andnotor]

La logique est de protéger la lecture et l'écriture puisque dans le premier exemple FGroupage pourrait déjà avoir changé entre le test et le verrou.

Et ne pas oublier de le faire au niveau du getter aussi. Protéger uniquement le setter n'aurait pas de sens

[der§en]

Si je comprend bien il faut protéger la variable même en lecture seul.

Merci pour vos réponses.

[sergio_is_back]

Si je comprend bien il faut protéger la variable même en lecture seul.

Merci pour vos réponses.

Normalement OUI !

L'utilisation de CriticalSection.Enter & Release n'est pas forcément très pénalisant, sauf si tu beaucoup de threads et que tu souhaite te rapprocher du temps réel, ou avoir des temps de cycle extrêmement courts

[der§en]

Normalement OUI !

L'utilisation de CriticalSection.Enter & Release n'est pas forcément très pénalisant, sauf si tu beaucoup de threads et que tu souhaite te rapprocher du temps réel, ou avoir des temps de cycle extrêmement courts

C’est exactement, ma problématique, d’où ma question !

[ShaiLeTroll]

Sinon plus compact InterlockedExchange ou AtomicExchange et InterlockedCompareExchange avec le type BOOL (LongBool)

Même si pour un Boolean, avec seulement deux états, la collision de valeur c'est plus savoir si il y a eu rétention lors du Setter.