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.

[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.

[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 un MREWS ?
Optimise la lecture fréquente ... mais faut pas imbriquer les verrous de lecture et d'écriture, faut mieux les séparer ce qui implique une double lecture

Code :

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

1
2
3
4
5
6
7
8
9
procedure TStefThread.GetGroupage(): Boolean;
begin
  FLogMREWS.BeginRead;
  try
    Result := FGroupage;
  finally
    FLogMREWS.EndRead;
  end;
end;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
procedure TStefThread.SetGroupage(Value: Boolean);
begin
  if GetGroupage() <> Value then // verrou en lecture
  begin
    FLogMREWS.BeginWrite; // Si cela se trouve, le BeginWrite a attendu qu'un autre thread modifie la valeur !
    try
      if FGroupage <> Value then // Un thread doit toujours supprimer les échantillons précédents de la mémoire protégée après avoir transformé un verrou de lecture en verrou d'écriture, ce qui est ce cas
        FGroupage := Value;
    finally
      FLogMREWS.EndWrite;
    end;
  end;
end;

Après le modèle des Setters de la VCL ou FMX où l'on teste avant d'affecter est surtout parce que l'affectation peut déclencher des choses, par exemple invoquer l'API Windows

Code :

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

1
2
      if FGroupage <> Value then
        FGroupage := Value;

le code est souvent plus complexe car le Setter appelle une autre méthode comme par exemple AdjustGroupage, le test évite l'appel inutile si la valeur n'a pas changé ..; tu aurais un code de ce type, le test de lecture me semblerait important mais là, est-ce que cela change quelques chose d'écrire la valeur si c'est déjà la même ...

Code :

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

1
2
3
4
5
6
7
      if FGroupage <> Value then
     begin
        if Assigned(OnBeforeChangeGroupage) then OnBeforeChangeGroupage(Self, FGroupage, Value);
        FGroupage := Value;
        AdjustGroupage();
        if Assigned(OnAfterChangeGroupage) then OnAfterChangeGroupage(Self, FGroupage, Value);
     end;

Sinon, il existe aussi TMonitor.Enter

[Paul TOTH]

une façon simple de régler ce problème (mais je ne sais pas si elle s'applique à ta problématique) est de ne mettre à jour la valeur que depuis le Thread principal et donc de passer par TThread.Synchronize pour le mettre à jour