2009-08-10 8 views
4

Je dois m'assurer qu'une fois que l'exécution a atteint une méthode, le contrôle reçu par cette méthode n'est pas modifié par un autre thread. En fait, je pensais à quelque chose comme ceci:Verrouiller un contrôle winforms

private void doSomeWork(Control control) { 
    lock (control) { 
     // do some stuff with the control... 
    } 
} 

Est-ce une mauvaise idée?

Edit:

En fait, ce que je suis en train de faire, est d'assurer que le contrôle ne sont pas éliminés par un autre thread alors que j'exécute une partie de par la manière, les méthodes de contrôle (qui, sera être exécuté par réflexion).

Répondre

3

Dans une application qui se comporte bien, les contrôles de formulaires Windows sont déjà limités à un seul thread. Si un thread tente d'accéder à un contrôle créé dans un thread différent, une exception sera levée.

Il n'y a rien de mal à propos de votre code, sachez que maintenant c'est surtout inutile à moins que vous ne vous frayiez un chemin à travers la protection (ce qui est possible).

Généralement, lorsque des données sont créées ou manipulées dans un thread opérationnel, le thread de travail envoie un événement au thread d'interface utilisateur pour mettre à jour l'interface utilisateur. En aucun cas, un thread de travail devrait mettre à jour l'interface utilisateur elle-même, il échouera automatiquement.

0

En fait Fernando, ce n'est pas une mauvaise idée mais ce n'est pas la bonne façon de regarder le verrouillage. Vous devez lire attentivement ce que la déclaration de verrouillage ne .Net:

http://msdn.microsoft.com/en-us/library/c5kehkcz(VS.80).aspx

je pense que de votre déclaration, vous attendez l'ensemble objet à verrouiller, ou être en quelque sorte en toute sécurité pour le filetage, car l'objet iteself est utilisé dans un bloc de code verrouillé. Ce qui se passe réellement, c'est que ce bloc de code est verrouillé et ne peut pas être exécuté par deux threads ou plus en même temps. Si ce bloc de code est le seul endroit où vous allez opérer sur le contrôle, alors tout va bien, sinon vous devrez faire des verrous de synchronisation sur l'objet lui-même.

0

Ne pas avoir beaucoup d'expérience de travail avec des fils, mais, peut-être que je vais vous suggère de commencer le contrôle de formulaire dans un nouveau thread en utilisant un délégué anonyme:

t= new Thread(delegate() { 
    MyMethodToInvokeTheWinFormControl(); 
    }); 

t.Start(); 
0

Cela dépend entièrement de ce vous voulez dire par "pas changé".

Si votre sens est "n'importe quel autre thread ne peut pas du tout changer ce contrôle", alors ce n'est pas comme ça que fonctionne le verrou. Un verrou dans ce sens n'est pas comme un verrou régulier sur une porte à une maison. C'est plus comme une petite note post-it jaune qui dit "Locked". Tant que les autres threads lisent la note et se conforment à ce qu'elle dit, ça devrait aller, mais tout autre thread qui ne se soucie pas de la note ne sera bien sûr pas empêché de jouer avec votre contrôle.

Dans tous les cas, qu'essayez-vous exactement d'accomplir? Vous ne devriez jamais être avec des commandes d'autres que le thread principal de sorte que le problème ne devrait pas exister en premier lieu. Au lieu de cela, vous devez rassembler tous les travaux sur le contrôle sur le thread principal à l'aide de la méthode Invoke sur le contrôle.

Questions connexes