Oui cela devrait marcher (j'ai juste lu, je n'ai pas testé !).
Le mutex permet de s'assurer que les différentes tâches seront exécutées les unes après les autres, et non en même temps. La simplicité ici vient que la gestion du thread qui exécute les fonctions est totalement laissé au système. Pas besoin de le créer soit même.
S'il n'y a pas beaucoup de tâches en attente, c'est méthode est tout à fait acceptable. S'il y en a beaucoup, je recommande l'utilisation d'un sémaphore binaire (=mutex) avec usage de async/await au lieu de l'instruction lock. En effet, avec l'instruction lock, tu vas réquisitionner un thread du pool de thread. Avec async/await, tu vas dire le libérer le temps de l'attente. Pour 3 tâches en attente max, ce n'est pas un soucis. Pour 200, c'est une autre histoire.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
|
public static class ThreadQueue
{
private static SemaphoreSlim mutex = new SemaphoreSlim (1, 1);
public static void QueueUserWorkItem(WaitCallback callBack)
{
WaitCallback cw = x =>
{
await semaphoreSlim.WaitAsync(); // on attend de récupérer le mutex
try
{
callBack.Invoke(null);
}
finally
{
semaphoreSlim.Release(); // on libère le mutex. Très important le bloc finally ici, car le mutex doit être libérer dans tous les cas, y compris quand il y a une exception dans le callBack !
}
};
ThreadPool.QueueUserWorkItem(cw);
}
} |
Juste une remarque : je ne vois pas l'utilité du
Thread.Sleep(1); dans la méthode
QueueUserWorkItem.
0 |
0 |