Discussion :

[gg2laba]

Bonjour � tous

je suis sous Builder 6.0

voil� j'aimerais faire une fonction qui ajouterais une ligne dans un fichier pour faire un fichier log mais cette fonction est appell�e par plusieurs threads ... esque ca pose un pb si ... il arrivais que 2 threads appele la fonction en meme temps ? ou est ce que je doit l'empecher avec des evenements ou un mutex ? ( la ca a l'air de tourner sans mais bon ... )

merci d'avance

[Neo41]

Bonjour,

dans ton cas l'utilisation d'une section critique ou d'une mutex est tr�s importante, parce tu risques de te retrouver avec un fichier dont le contenu est le m�lange des deux threads (si � un instant X les 2 l'ouvrent en m�me temps) !

En r�gle g�n�rale, du moment o� une t�che peut �tre exc�cut�e par plusieurs threads, il faut prot�ger l'acc�s par une section critique.

[gg2laba]

merci de la reponse :

hmm d'accord ca veut donc dire que une fonction peut etre execut� plusieur fois en meme temp par different threads ? donc je peut faire un truc du genre :

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
void AddLog(AnsiString Message)
{
   //Attendre que le Mutex soit Libre
   ...
 
   //Ajout de Message à la fin du fichier
   fstream FichierLog;
 
   FichierLog.open("LogFile.txt",ios_base::out|ios_base::app);
   if (!FichierLog)
   {
      ShowMessage("Impossible d'ouvrir le fichier log");
   }
   else
   {
      Message=AnsiString("\nle "+DateToStr(Date())+" a "+TimeToStr(Time())+" "+Message);
      FichierLog.write(Message.c_str(),Message.Length());
   }
   //Liberer le mutex
   ...
}

?

et je n'ai pas besoin de le faire a chqque appel de fonction comme :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
   ...
   //Attendre que le Mutex soit Libre
   ...
 
   AddLog("Erreur");
 
   //Liberer le mutex
   ...

?

[Christophe Brun]

Exact. Je dirai m�me que tu dois utiliser du code prot�g� dans AddLog() et non pas prot�ger de l'ext�rieur les appels � AddLog(). Cette deuxi�me m�thode est peu fiable car sensible aux erreurs (aux oublis surtout).

NB : comme pour tous ce que touche aux allocations/lib�rations de ressources, il faut �tre attentif � garantir que toute ressource allou�e est lib�r�e. Ici, si tu acquiers un mutex, il faut �tre absolument s�r que tu le lib�res avant de quitter la m�thode. C'est � dire : avant n'importe quelle instruction return ou malgr� n'importe quelle lev�e d'exception.

En cas de doute (surtout sur les exceptions), utiliser le principe RAI (resource acquisition is initialization). 8)

[Neo41]

Bonjour,

un conseil concernant l'utilisation des mutex et des sections critiques: Il faut toujours faire le Acquire et le Release dans un bloc Try/finally. Parce que si tu fais un Acquire et qu'apr�s t'as une exception, alors tu vas sortir de la m�thode sans avoir relach� la main.Oups...

Donc en gros:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
try
{
  SectionCritique->Acquire();
  //Code...
}
__finally
{
  SectionCritique->Release();
}

Bon courage

[gg2laba]

merci pour votre aide je vois ce que j'ai a faire !
Neo41 :

Bon courage

mici !!

[Christophe Brun]

NB : try / __finally fonctionne bien, mais __finally est une instruction native de Borland. Elle n'existe pas dans la norme du C++.
Si vous voulez garantir un minimum de portabilit� (encore que... une fois sous Borland, si on utilise la VCL, on devient assez peu portable...), utiliser une classe enveloppe (sur le mod�le RAI dont je parlais plus haut) est simple et efficace :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
 
class Mutex; // un mutex quelconque à acquérir/libérer
class MutexHandler { 
  public : 
  Mutex Handler( Mutex& m ) : m_mutex( m ) 
  { m_mutex.acquire(); }
  virtual ~MutexHandler() 
  { m_mutex.release(); }
  private : 
  Mutex& m_mutex;
};

Et comme utilisation :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
void addLog() {
  ...
  // Tentative d'acquisition 
  MutexHandler mh( *( new Mutex ) );
  // Code éventuellemment susceptible de cacher un return ou une exception
  ...
}

L'appel � Mutex::release() se dont fait automatiquement et sans erreur possible en quittant la m�thode, quel que soit le point de sortie. 8)