Discussion :

[laurent_r]

Bonjour,
Je cherche à faire une synchronisation sur une liste en delphi.net.
Je peux avoir deux threads différent qui accède la même liste et je voulais savoir comment je pouvais le faire (genre semaphore) mais je sais pas en delphi.net.

Merci

[ShaiLeTroll]

Regarde si la TThreadList existe en .NET, elle est fait pour ça !
Sinon, TCriticalSection

Ce sont des objets VCL, j'ignore si il existe en Merdasse.NET

[Aka Guymelef]

Bonjour,

La chose qui semble le plus s'approcher de la TThreadList serait la classe ThreadPool du namespace System.Threading.

Bon après quoi qu'il en soit, il faut aller farfouiller à l'intérieur de ce namespace pour trouver ce que tu cherches car tout ce qui se rapporte aux Threads est à l'intérieur.

[ShaiLeTroll]

un ThreadPool,c'est pour gérer un ensembe de thread, c'est un peu lourd pour gérer par pour la communication inter-thread via un FIFO

Il te faudrait surcharger une "System.Collections.ArrayList" et utilisé le mot clé lock ou par la classe System.Threading.Semaphore

Quel est donc bien l'intérêt de Delphi.NET si on peut pas avoir un Borland.SyncObjs.TThreadList qui encapsule la merdasse.NET, ... je ne pensais pas que Delphi.NET était aussi éloigné de Delphi Win32 ... c'est vraiement apprendre un nouveau langage ...

[laurent_r]

En effet le thread pool me sert à rien dans mon cas ...
La classe System.Threading.Semaphore, je n'ai pas trouvé dans delphi.net (2006) mais il y a le System.Threading.ReaderWriterLock qui a l'air pas mal !

[Laurent Dardenne]

j'ignore si il existe en Merdasse.NET

Tu as tout à fait le droit de ne pas apprécier .NET, mais n'en dégoûte pas les autres

[laurent_r]

Tu as tout à fait le droit de ne pas apprécier .NET, mais n'en dégoûte pas les autres

Je suis tout à fait d'accord, surtout que c'est pas parce que c'est microsoft que sa doit forcément être de la m....
Il y a quand même des points positifs et négatif comme partout !!
Par contre je suis pas sûr que le delphi soit une bonne chose mais bon il fallait bien qu'ils se mettent au goût du jour... Pour ma part j'aurais préféré faire en C# mais je n'avais pas trops le choix

[ShaiLeTroll]

Tu as tout à fait le droit de ne pas apprécier .NET, mais n'en dégoûte pas les autres

Désolé, pour moi faire du .NET avec du Delphi est une hérésie !

Je suis tout à fait d'accord, surtout que c'est pas parce que c'est microsoft que sa doit forcément être de la m....

Oh ce n'est pas parce que MicroSoft, c'est juste que je n'aime pas ce concept d'assistanat de développeur qu'introduit le .NET sans la réelle efficience du mutli-plateforme via cocoa# ou mono, alors que Java le fait déjà depuis bien longtemps ... j'ai du faire des objets COM pour de l'inter-opérabilité avec des partenaires en .NET, il n'était même pas capable de me fournir leur convention d'appel qui est safecall, ce qui influe sur la manière de créer ses fonctions dans l'éditer de TLB de Delphi 7, et à chaque fois que j'ai travaillé avec des collaborateurs en .NET, que ce soit en COM ou en WebService, ils utilisent une tétra-chier de produit MS avec lesquels, il est très difficile de communiquer sans disposer soit même du FrameWork ... c'est comme si les développeurs avaient oubliés comment il faisait il y a encore quelques années c'est à dire qu'avec un trombone on faisait décoler une fusée alors que maintenant avec un semi-remorque c'est à peine si l'on peut expédier une épingle ...

... Pour ma part j'aurais préféré faire en C# mais je n'avais pas trops le choix

Entièrement d'accord, quite à apprendre le Framework .NET autant le faire avec un langage nativement étuidié pour !
Vous noterez que j'ai argumenté toutes mes propositions avec la MSDN, si je ne fait pas de C# ou de Delphi.NET, je sais quand même m'y retrouver car je tiens à me tenir au courant de cet outil qui pourrait me servir un jour dans ma carrière ...

Sinon pour en revenir au sujet, ce System.Threading.ReaderWriterLock doit être l'équivalent du TMultiReadExclusiveWriteSynchronizer de Delphi

Pour System.Threading.Semaphore apparait en Visual Studio 2005/.NET Framework 2.0, Delphi 2006 est en 1.1, il faut passer à Delphi 2007 pour le 2.0 ...

[laurent_r]

ce concept d'assistanat de développeur qu'introduit le .NET sans la réelle efficience du mutli-plateforme via cocoa# ou mono, alors que Java le fait déjà depuis bien longtemps ...

Je ne suis pas un admirateur de .net (je me tiens aussi au courant des nouvelles tendances) mais je tiens à dire que l'on peut quand même apprécier l'assistance au développeur en général (se qui est déjà fait par des librairies qui évitent de devoir réinventer la roue à chaque fois (merci au langage Orienté Objet) et aussi par les interfaces graphiques de MS qui permettent aussi de faciliter l'accès/gestion base de donnée et création de UI).
Est le .net contrairement à Java est de rendre ou essayé de rendre différent langage compatible entre eux autour d'un même framework. Java fais du multi-plateforme mais avec le même langage!

[ShaiLeTroll]

... devoir réinventer la roue à chaque fois

C'est étrange, ce n'est pas ce que tu es en train de faire ? Avant, tu aurais pris une TCriticalSection ou une TThreadList, maintenant, tu perds ton temps à compendre ce MicroSoft à ré-inventé ...

D'ailleurs, une fois que tu auras fait un code interessant et ré-utilisable n'hésite pas à le partager, ...

Réinventer la Roue ! C'est pourtant tellement interessant, pire, c'est le plus interessant, c'est même le fondement même l'informatique, toujours revoir, améliorer, refaire, tout en étant compatible pour qu'un plus grand monde puisse y passer, si il n'y avait des gens pour réinventer ce qui existe, on aurait pas de FastMM, pourquoi le faire alors qu'il y avait déjà un MemoryManager dans la VCL, on aurait pas de MPEG4, pour faire un nouveau format, alors qu'on en a déjà un ! On aurait pas le .NET puisqu'il y avait déjà JAVA

D'ailleurs, actuellement BOSE, réinvente la roue, en y incluant une suspension magnétique ou comme Michelin qui a repris le principe l'inclusion du moteur dedans et prévoit sa commercialisation prochaine !
Merci à tous ceux qui réinvente la Roue !

[laurent_r]

Réinventer la Roue ! C'est pourtant tellement interessant, pire, c'est le plus interessant, c'est même le fondement même l'informatique, toujours revoir, améliorer, refaire, tout en étant compatible pour qu'un plus grand monde puisse y passer, si il n'y avait des gens pour réinventer ce qui existe, on aurait pas de FastMM, pourquoi le faire alors qu'il y avait déjà un MemoryManager dans la VCL, on aurait pas de MPEG4, pour faire un nouveau format, alors qu'on en a déjà un ! On aurait pas le .NET puisqu'il y avait déjà JAVA

Je vois pas ce qu'il y a d'intéressant à part à "l'école" pour mieux comprendre certaines chose. Sinon c'est pas réinventé c'est améliorer ce qui est pas la même chose. Repartir d'une chose existante pour en refaire les fondements par rapport aux experiences est quelque chose d'utile. Le MPEG4 est pas venue du premier coups car justement il y a eu amélioration et on n'a pas refait la même chose qui existait en le renommant différement.
Le .NET comme je l'ai expliqué ne va pas sur le même territoire que JAVA. Deux idées différentes donc pas de réinvention de se côté là. Par contre il est vrai qu'il s'appuie sur des notions déjà existante.
Bon je pense que ce sujet peux être discuter en long et large ...

Merci à tous ceux qui réinvente la Roue !

Alors je dis merci à tous ceux qui améliore et recherche de nouveaux fondement pouvant apporter quelques chose d'intéressant

[Laurent Dardenne]

Puisqu'on en est aux remerciements, je vous remercie d'aller troller dans la taverne, dédiée entre autre à cette usage.
Merci.