Explication du texte sur Threading dans « C # 3.0 in a Nutshell »

Question

Lors de la lecture C # 3.0 in a Nutshell par Joseph et Ben Albahari , je suis tombé sur le paragraphe suivant (page 673, premier paragraphe l'article intitulé " signalisation avec Wait et Pulse ")

  

" Moniteur classe fournit une autre signalisation construction par deux méthodes statiques, Attendez et Pulse . Le principe est que vous écrivez la logique de signalisation vous en utilisant des drapeaux personnalisés et des champs (entre verrouillage des déclarations ), puis introduire Attendez et Pulse commandes pour atténuer le filage du processeur. L'avantage de cette approche de bas niveau est que, avec juste Attendez , Pulse et verrouillage déclaration, vous pouvez obtenir la fonctionnalité de AutoResetEvent , ManualResetEvent et Sémaphore , ainsi que WaitHandle 's méthodes statiques WaitAll et WaitAny . En outre, Attendez et Pulse   peut se prêter dans des situations où   toutes les poignées d'attente sont   parcimonieusement remis en cause. "

Ma question est, quelle est l'interprétation correcte du dernier phrase?

• Une situation avec un nombre décent / grand nombre d'attente poignées où WaitOne () est appelée uniquement de temps en temps sur une poignée d'attente particulière.
• Une situation avec un nombre décent / grand nombre d'attente poignées où il est rare que plus d'un fil ont tendance à bloquer sur une poignée d'attente particulière.
• Une autre interprétation.

apprécierions également des exemples éclairants de ces situations et peut-être comment et / ou pourquoi ils sont plus efficacement traitées par Attendez et le pouls plutôt que par d'autres méthodes.

Merci!

Edit: J'ai trouvé le texte en ligne

Answer 1

Qu'est-ce que cela veut dire est qu'il ya des situations où attente et Pulse fournit une solution plus simple que d'attendre les poignées. En général, cela se produit où:

• Le serveur, plutôt que le notifiant, décide quand débloquer
• La condition de blocage implique plus qu'un simple indicateur (peut-être plusieurs variables)

Vous pouvez toujours utiliser attente poignées dans ces situations, mais attendez / Pulse a tendance à être plus simple. La grande chose au sujet Wait / Pulse est que Wait libère le verrou sous-jacente en attendant. Par exemple, dans l'exemple suivant, nous lisons _x et _y au sein de la sécurité d'une serrure - et pourtant ce verrou est libéré en attendant de sorte qu'un autre thread peut mettre à jour ces variables:

lock (_locker)
{
  while (_x < 10 && _y < 20) Monitor.Wait (_locker);
}

Un autre fil peut ensuite mettre à jour _x et _y atomiquement (en vertu de la serrure), puis d'impulsions pour signaler au serveur:

lock (_locker)
{
  _x = 20;
  _y = 30;
  Monitor.Pulse (_locker);
} 

L'inconvénient de Wait / Pulse est qu'il est plus facile de se tromper et de faire une erreur (par exemple, en mettant à jour une variable et à oublier Pulse). Dans les situations où un programme avec des poignées d'attente est tout aussi simple à un programme avec Wait / Pulse, je vous recommande d'aller avec attente poignées pour cette raison.

, Wait / Pulse est généralement plus rapide et plus léger (comme il a une mise en œuvre géré) (vous allusion, je pense que) En ce qui concerne la consommation d'efficacité / de ressources. Ce qui est rarement une affaire dans la pratique, cependant. Et sur ce point, Framework 4.0 inclut des versions gérées à faible surcharge de ManualResetEvent et Sémaphore (ManualResetEventSlim et SemaphoreSlim).

Framework 4.0 fournit également de nombreuses options de synchronisation qui réduisent la nécessité d'attente / Pulse:

• CountdownEvent
• Barrière
• PLINQ / données Parallélisme (AsParallel, Parallel.Invoke, Parallel.For, Parallel.ForEach)
• Tâches et continuations

Tous ces éléments sont de niveau supérieur beaucoup plus que d'attendre / Pulse et de l'OMI sont préférables pour l'écriture de code fiable et maintenable (en supposant qu'ils vont résoudre la tâche).