Discussion :

[[ZiP]]

Bonjour,

Comment dois-je faire pour partager un TStringList de mon application entre plusieurs threads de manière à ce que les modifications de cette TStringList ne soient pas réalisées en même temps.

Merci,
ZiP

[delphichem]

Si tu utilises un TThread, tu peux utiliser la méthode Synchronize, sinon tu peux utiliser des sections critiques.

[Rayek]

Il serait bien de nous dire ce que tu veux faire avec cette TStringList et ces threads

[[ZiP]]

En fait, je souhaite partager une TStringList entre plusieurs thread afin que je puisse ajouter et supprimer de lignes dans cette TStringList depuis n'importe quel thread.

[Rayek]

En fait, je souhaite partager une TStringList entre plusieurs thread afin que je puisse ajouter et supprimer de lignes dans cette TStringList depuis n'importe quel thread.

Oui, oui, ça on a compris, mais concrètement ton programme il va faire quoi ?

Car autant tu prends une mauvaise direction en voulant absolument que les threads lisent dans la TStringList alors qu'autant tu pourrais faire en sorte que ce soit la TStringList qui contrôle les Threads.

[[ZiP]]

Les threads liront des pages Internet, et placerons les liens trouvés dans une TStringList globale.
Chaque thread supprimera la première ligne de la liste afin de l'utiliser.

J'espère avoir été assez clair.

ZiP

[delphichem]

Tu peux créer une méthode pour ton thread pas ex: SyncList:

Code :

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

1
2
3
4
5
6
7
8
9
function TMonThread.SyncList;
begin
  Result := '';
  if SL.Count > O then
  begin
    Result := SL[0];
    SL.Delete(0);
  end;
end;

Et dans ton code tu fait appel a cette methode par le biais de

Code :

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

Synchronize(SyncList);

[[ZiP]]

Faut-il quand même que j'utilise des sections critiques afin d'éviter des erreurs ?

ZiP

[Linkin]

C'est le travail du Synchronize normalement.

[Reisubar]

Le plus simple pour moi (non testé):

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
class TThreadedStringList = class (TStringList)
private:
  FLockCS: TCriticalSection;
public:
  procedure Lock();
  procedure Unlock();
end;
 
procedure TThreadedStringList.Lock()
begin
  FLockCS.Acquire;
end;
 
procedure TThreadedStringList.Unlock()
begin
  FLockCS.Release;
end;

et dans ton code, avant tu encadres les sections qui manipulent tes strings list de Lock() et Unlock() :

Code :

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

1
2
3
4
5
6
7
...
MySL.lock();
try
...
finally
  MySL.Unlock();
end;

Je pense qu'il est mieux quand on peut d'éviter de faire appel à Synchronize. La méthode la plus simple de synchronisation, c'est les sections critiques...

[delphichem]

C'est le travail du Synchronize normalement.

Oui c'est exactement ça.

[Reisubar]

Synchronize() n'est pas une primitive de synchronisation comme en Java. C'est un bricolage qui permet de faire exécuter une procédure au thread principal en utilisant les messages Windows. Il y a de nombreux cas ou Synchronize() ne fonctionnera pas (applications console, etc.) et de nombreux bugs qui vont avec (lire les newsgroups anglophones). Tu fais ce que tu veux, mais personnellement je te conseille d'utiliser de vrais objets de synchro pour faire de la synchro

[Linkin]

Content de le savoir, c'est vrai que je m'étais basé sur le fonctionnement du Synchronize de Java

[delphichem]

J'utilise synchronize dans tous mes programmes multi threader, je n'ai "encore" jamais eu de problèmes, peux être ont ils étaient corrigé sur RAD studio 2007?
Mais merci pour l'info, j'envisagerai dans mes future développement de m'en passer.

[Reisubar]

Ce n'est pas vraiment des bugs, mais plus des soucis de conception qui sont propices à des deadlocks. J'ai retrouvé un thread sur google qui en parle :
http://newsgroups.cryer.info/borland...707318688.html

Personnellement, j'utilise synchronize() sous D2007 sans problème. Mais je me cantonne à son utilisation de base : poster une demande d'exécution de procédure au thread principal. Dans le post, on voulait rendre un objet threadsafe, et non déférrer tous les accès aux thread principal, c'est pour cela qu'un objet de synchro est suffisant...