Design accès exclusif TcpCLient

Bonjour,

je reprends un de mes vieux codes qui me donne pas satisfaction niveau design. J'ai 1..N Threads qui se partagent une connexion TcpClient. L'accès est exclusif, et j'essaie de prioriser les demandes d'écritures avant les demandes d'interrogations.

Dans mon ancien design, chaque thread qui était en charge d'une action (lecture ou écriture, les lectures sont périodiques, les écritures ponctuelles) s'inscrivait dans une file, puis testait régulièrement si c'était son tour, faisait son office quand il avait la main puis faisait un sleep pour marquer une période d'interrogation... :oops:

J'aimerais rendre l'accès plus dynamique. Je pensais utiliser les AutoResetEvent, que tous les threads soient en Wait et que celui qui ait fini de taffer fasse un Set, mais :
* Comment gérer si j'ai un seul Thread ? AutoresetEvent tombe à l'eau alors, car personne ne pourra réveiller le thread
* Comment gérer si le thread qui finit son taff fait le Set alors que les autres dorment et n'ont pas encore fait un Wait pour marquer leur désir de nouveau utiliser le TcpClient ?

AutoResetEvent me semblait alléchant mais semble poser d'autres soucis de design. Si possible j'aimerais ne pas reposer sur des lock.

Hello, je n'ai jamais utilisé AutoResetEvent, mais de ce que j'ai pu comprendre:

* Comment gérer si j'ai un seul Thread ? AutoresetEvent tombe à l'eau alors, car personne ne pourra réveiller le thread
>> Ca implique que le tout premier Set doit être effectué par un autre thread, par exemple dès la création de l'AutoResetEvent:

Citation:

---

You can control the initial state of an AutoResetEvent by passing a Boolean value to the constructor: true if the initial state is signaled and false otherwise.

---

Source: https://msdn.microsoft.com/fr-fr/lib...vs.110%29.aspx


* Comment gérer si le thread qui finit son taff fait le Set alors que les autres dorment et n'ont pas encore fait un Wait pour marquer leur désir de nouveau utiliser le TcpClient ?
>> L'AutoResetEvent mémorise le fait qu'un Set a été envoyé, mais pas encore consommé. Le prochain thread qui fera un WaitOne dessus consommera ce Set un s'exécutera immédiatement.

Citation:

---

A thread waits for a signal by calling WaitOne on the AutoResetEvent. If the AutoResetEvent is in the non-signaled state, the thread blocks, waiting for the thread that currently controls the resource to signal that the resource is available by calling Set.

Calling Set signals AutoResetEvent to release a waiting thread.AutoResetEvent remains signaled until a single waiting thread is released, and then automatically returns to the non-signaled state. If no threads are waiting, the state remains signaled indefinitely.

If a thread calls WaitOne while the AutoResetEvent is in the signaled state, the thread does not block. The AutoResetEvent releases the thread immediately and returns to the non-signaled state.

---

ok, j'avais mal interprété le AutorResetEvent, je pige mieux la différence avec le Manual !

Merci