Discussion :

[jbat]

Bonjour.

Suite à mon dernier post sur ce forum, j'ai une question légèrement différente...

Je voudrais votre avis sur une question...

J'ai un programme qui écrit dans une ressource partagée et un timer qui lit dans cette même ressource. Pour éviter les conflits d'accès, vaut-il mieux utiliser une section critique ou un mutex ?

Je suis dans le flou car le timer fait parti du thread principal de l'application, mais en même temps, un timer dérive d'un thread donc je sais plus trop...

[ShaiLeTroll]

Attention ne pas confondre Thread et Timer ...

Un Thread tournera de façon indépendante du Thread VCL ...

Un Timer est mécanisme Windows qui lance à un cycle donné une procédure ou emet un message WM_TIMER, ... pour le TTimer de Delphi c'est un Message, donc cela ne se produit que dans un Application.ProcessMessage ou dans le Idle de la Boucle Run mais pas en dehors ...

Donc si il n'y a pas d'Application.ProcessMessage dans ton gestionnaire de OnTimer (ce qui est très dangereux car risque d'empilement de procédure dans la pile), tu ne devrais n'avoir aucun soucis, car les messages sont gérés en FIFO donc pas d'accès concurrent entre Deux Timer d'un même Thread ...

Sinon pour un Thread soit une SectionCritique très facile à utiliser, soit un TMultiReadExclusiveWriteSynchronizer
qui permet une seule écriture en cours mais n'empeche pas la lecture de plusieurs process ....

[gb_68]

Bonjour,

la différence entre Section Critique et Mutex est que le premier agit entre thread d'un même processus et que le second agit entre les processus eux mêmes.

Ainsi si ta ressource est interne au processus ou n'est pas accèdée hors de ce processus une Section Critique suffit.

Remarque : un exécutable lancé crée généralement un seul processus avec un thread principal (mais peu en lancer d'autres processus par ShellExecute, CreateProcess, ... fork-linux-).

Pour les timer, le TTimer utilise comme l'a expliqué ShaiLeTroll la boucle des message du thread principal de la VCL et ne necessite donc pas en général de synchronisation.

Mais pour un timer de type timeSetEvent des problèmes de synchronisation peuvent se poser.

[jbat]

J'utilise un seul et simple TTimer de la VCL. Lequel TTimer fait parti de mon programme.

Mais les collisions ne sont pas à craindre entre plusieurs appels de l'évènement OnTimer, mais plutôt, entre :
- l'écriture dans le fichier par une procédure du programme
et par
- la lecture + suppression dans le fichier par l'évènement OnTimer.

Donc Si j'ai bien compris le dernier message, une section critique serait plus appropriée dans mon cas.?..

En tout cas, merci de vos réponses.

[ShaiLeTroll]

Ton Ecriture est dans un Bouton ?
Ta Lecture est dans un Timer ?

Donc tu ne peux pas avoir de conflit, sauf si tu as mis un Application.ProcessMessages, mais sinon encore plus simple dans ton bouton
tu fais Timer.Enabled := False, et retour à true à la fin ... comme ça pas de soucis non ?

[Paul TOTH]

J'utilise un seul et simple TTimer de la VCL. Lequel TTimer fait parti de mon programme.

comme le dit le Shai, tu ne peux pas avoir de conflit dans ce cas, les messages ne sont traités que lorsque l'application ne fait rien d'autre...si tu fais un traitement dans un OnClick par exemple, aucun autre évènement (y compris d'un timer) ne peut être déclenché...à moins d'invoquer Application.ProcessMessages qui justement traite les messages en attente.

mais même dans ce cas, la section critique ou le mutex sont inutils, une simple variable booléenne suffira !

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
24
25
26
 
procedure Tform1.Timer1OnTimer(Sender:TObject);
begin
 if Busy then exit;
 Busy:=True;
 try
  ... traitement...
 finally
  Busy:=False;
 end;
end;
 
procedure TForm1.Button1Click(Sender:TObject);
begin
 if Busy then exit;
 Busy:=True;
 try
  ... début traitement...
  Application.ProcessMessages; 
 { si le OnTimer est déclenché, il ne fera rien (Busy=True) }
 { d'autre part, le traitement ici est suspendu pendant le traitement des messages }
  ... suite traitement...
 finally
  Busy:=False;
 end;
end;