Comment trouver un interblocage et l'empêcher en C #

Outils d'analyse des performances peut également être utile dans l'identification des blocages, entre autres. Cette question permettra de donner un aperçu dans cette rubrique: C#/.NET outil d'analyse pour trouver des conditions de course/blocages .

Analyse visuelle du code et de la bonne utilisation de verrous est utile aussi (vous devriez être en mesure de détecter les problèmes potentiels dans le code lors de l'inspection), mais peut être très difficile pour les applications les plus complexes. Parfois, les blocages sont visibles uniquement lorsque vous exécutez le code, pas simplement en inspectant le code.

Je ne sais pas trop de votre interlocuteur. Certains voudront peut-être voir combien vous savez de verrouillage de normes ou de principes, certains peuvent vouloir voir si vous savez comment l'utiliser vos outils, certains voudront peut-être les deux. Dans la société où je travaille, par exemple, l'utilisation d'outils (notamment ceux que nous avons déjà propre et utilisation) est très appréciée. Mais cela n'implique pas, on ne doit pas avoir les compétences qui permettrait d'éviter le codage des blocages dans la première place.

Verrouillage quelque chose juste pour le plaisir de verrouillage affecte les performances, comme fil d'attendre les uns des autres. Vous devez analyser le flux de travail afin de déterminer ce qui a vraiment besoin d'être verrouillé, quand, avec quel type de serrure (simple lock ou peut-être un Readerwriterlockslim).
Il existe de nombreuses typique des moyens pour éviter l'impasse.

Par exemple lors de l'utilisation de Readerwriterlockslim vous pouvez utiliser un délai d'attente pour éviter les blocages (si vous attendez trop, vous abord l'acquisition de la serrure) http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

if (cacheLock.TryEnterWriteLock(timeout))
{
...
}

Et vous devriez être en mesure de proposer de tels délais d'attente.

À une telle question que je voudrais attendre au moins une mention de la classique de cas de blocages, comme la mauvaise utilisation de imbriqués les verrous (vous devriez être en mesure de connaître peut vous éviter d'eux, pourquoi ils sont mauvais, etc.).

Le sujet est très grand... vous pouvez aller sur et sur ce sujet. Mais sans definitios. Savoir ce qu'est une serrure et de savoir utiliser des verrous/sémaphores/mutex à grande échelle et multi-threding applications sont 2 choses différentes.

Je pense que l'interview est de vous poser une question piège. Si vous pouviez utiliser l'analyse statique pour éviter l'impasse... personne n'aurait l'impasse!

Personnellement, quand je regarde pour le blocage, je commence par trouver les fonctions où la section critique s'étend sur plus de l'appel de la fonction. Par exemple

void func(){
    lock(_lock){
        func2();
     }
}

Ce n'est pas vraiment clair ce que func2 est en train de faire. Peut-être qu'il distribue un événement sur le même thread, ce qui signifie que l'événement est toujours une partie de la section critique. Peut-être que c', puis verrouille sur un différents de verrouillage. Peut-être qu'il distribue dans le pool de threads et de plus est re-venu en raison de son désormais sur un autre fil! Ces sortes de lieux où vous pouvez commencer à voir des scénarios de blocage qui se passe: lorsque vous avez plusieurs non réentrant de verrouillage endroits.

D'autres fois, lors du traçage des scénarios de blocage, je revenir en arrière et j'essaie de trouver où sont tous les threads créés. Je donne la pensée de chaque fonction et où il peut être en cours d'exécution. Si vous n'êtes pas sûr, en ajoutant à l'enregistrement pour vous connecter à l'appel est venu de peut aussi aider.

Vous pouvez également éviter les blocages en utilisant verrouillage de libérer des structures de données (mais ceux-ci exigent autant de bien qu'à l'utilisation). Vous souhaitez réduire votre accès à la serrure libre de la structure parce que chaque fois que vous accédez à ce qu'on peut changer.

Comme mentionné dans une autre réponse, vous pouvez utiliser les mutex avec des délais d'attente, mais qui n'est pas garanti pour toujours travail (si votre code doit travailler plus longtemps que le délai d'attente?). Il a été mentionné dans un autre commentaire que c'est peut-être ce que l'intervieweur demandait. Je trouve que dans la production, ce n'est pas vraiment une bonne idée. Délais d'attente varient tout le temps, peut-être que quelque chose a pris plus de temps que prévu à courir et frapper un délai d'attente. Je pense que c'est mieux de le laisser impasse, les processus de vidage, puis de trouver exactement ce qui retenait les serrures et de résoudre le problème. Bien sûr, si les besoins de votre entreprise ne peut pas permettre cela, alors vous pouvez l'utiliser dans le cadre d'une défensive stratégie de codage avec verrouillage intelligent choix de placement.

Je ne suis pas d'accord avec votre entrevue qui verrouille toujours ajouter un énorme problème de performance. Uncontended serrures/mutex/etc premier test comme un spinlock avant de passer au large à l'OS et spinlocks sont bon marché.

En général, la meilleure façon d'éviter un blocage, est de comprendre le flux de programme. Chaque fois que vous introduisez un nouveau verrou de l'objet de réfléchir à l'endroit où il est utilisé et utilise la chaîne.