none
Monitor, lock multithreading RRS feed

  • Question

  • Salut a tous !

    Je cherche a ce que mon code ait l'accès exclusif a un objet.

    Le monitor ou l'instruction lock semble de prime abord répondre à cela. Cependant la doc Microssoft parle de section de code critique et autres. Or moi je ne veux pas seulement bloquer l'acces a cette portion code mais aussi a toute autre portion de code dans mon programmequi voudrais modifier mon objet (meme instance).

    Alors je pose la question d'apres vous l'instruction lock ou l'utisation du Monitor sont ils ce qu'il me faut et si non comment faire ?

    Merci !
    lundi 11 août 2008 12:22

Toutes les réponses

  • Salut,

      Personnellement je partirai sur un singleton (fais une tite recherche sur le forum j'avais posté un exemple je crois) histoire de n'avoir qu'une instance de ton objet.

      Aprés ca dépend de ce que tu veux faire...si tu veux "mettre en attente" les modifications de ton objet tant qu'un traitement est en cours le plus simple me semble le lock. Par contre si tu veux par exemple lever une exception si un objet tente de modifier le contenu d'une variable pendant que tu fais un traitement la c'est plutot avec un boolean que je le ferai...

      Rapidement ca pourrais donner ca : (non testé et vite fait)

    Code Snippet

    public class maclass

    {

      ...

      private int _value;

      public static int Value

      {

        get { return _instance._value; }

        set

        {

          if (_instance._IsBusy)

            throw new Exception("blabla");

          else

            _instance._value = value;

        }

      }

      ...

      public static void Traitement()

      {

        _instance._IsBusy = true;

        ...

        _instance._IsBusy = false;

      }

      ...

    }

     

     

    Appel :

    maclass.Traitement();

    et si une autre classe dans le code fait "maclass.Value = 2;" alors que "Traitement" n'est pas terminé tu auras une exception...

     

    Bon c'est qu'une idée comme ca hein Wink a voir si ca colle avec ce que tu souhaites!

    A+,

          Stéphane

    mardi 12 août 2008 11:06
  • Je confirme (comme DarkAngel_FR) que c'est bien lock que tu dois utiliser (voire monitor si tu veux un peux plus de souplesse avec le TryEnter pour éviter les deadlocks)

     

    Si tu avais des opérations très basiques tu pourrais utiliser interlocked mais ici tu parles de portions entières de code donc un petit lock(this) sera parfait.

     

    Quand à utiliser le singleton (dont je suis aussi un fan), je ne saurai te dire ici. Tout dépend en fait de ton code et de l'accessibilité de la partie à verrouiller. Si tu en veux un néanmoins je te conseille l'excellent site de dofactory avec une version optimisée du singleton (http://www.dofactory.com/Patterns/PatternSingleton.aspx)

     

    mardi 12 août 2008 12:01
  •  

    Yop j'ai trouver sur le net.

     

    Je veut pouvoir avoir plusieurs instance donc le singleton ne convient pas mais on n'est pas tres loin.

     

    quelque chose comme

     

    Code Snippet

    public class maClasse

    {

    private object mylock = new object();

     

     private string _myValue = null;  
     
        public string MyValue  
        {  
            get { lock (myLock) { return _myValue; } }  
            set { lock (myLock) { _myValue = value; } }  
        }  
     
        public void MyMethod  
        {  
            lock (myLock)  
            {  
                // do something  
            } 

        }

    }

     

     

     

     

    L'instance s'assurant elle meme des locks tout est thread safe.

     

    Vous en pensez quoi ?

     


     

     

    jeudi 14 août 2008 07:01
  • Ca me parait pas mal car le lock verrouille tout (get, set et mymethod).

     

    Par contre tu n'as peut être pas besoin de faire un lock(mylock). A mon avis un lock(this) doit amplement suffire et t'économiser un objet.

     

    As tu vraiment besoin de locker le get ?

    jeudi 14 août 2008 13:19
  • Le lock sur un membre privée evite les deadlock avec des codes externe qui ferait un lock sur mon instance.

     

    Le lock sur le get n'est probablement pas util sur un type comme une string mais si mon membre est complexe ou la fonction get l'est, alors le membre pourrait etre modifier au cours de l'execution du get ou du passage de l'objet et le resultat risquerait d'etre incoherent enfin me semble t'il. Et puis je viens de decouvriri les lock alors j'en met partout !!! (non c'est pas vrai)

     

     

    jeudi 14 août 2008 15:38