Différence entre le verrouillage manuel et les méthodes synchronisées

Question

Y-a-t-il une différence entre ceci :

internal class MyClass
{
    private readonly object _syncRoot = new Object();

    public void DoSomething() 
    {
        lock(_syncRoot)
        {
            ...
        }
    }

    public void DoSomethingElse() 
    {
        lock(_syncRoot)
        {
            ...
        }
    }
}

et ceci :

internal class MyClass
{
    [MethodImpl(MethodImplOptions.Synchronized)]
    public void DoSomething() 
    {
        ...
    }

    [MethodImpl(MethodImplOptions.Synchronized)]
    public void DoSomethingElse() 
    {
        ...
    }
}

La seule différence que je vois est que la première approche verrouille un membre privé alors que la seconde approche verrouille l'instance elle-même (elle devrait donc verrouiller tout le reste de l'instance). Y a-t-il un conseil général sur l'approche à utiliser ? J'ai actuellement trouvé deux classes avec un objectif similaire dans notre projet, chacune écrite avec une approche différente.

Editar:

Peut-être une autre question. Est-ce que c'est ça :

internal class MyClass
{
    [MethodImpl(MethodImplOptions.Synchronized)]
    public void DoSomething() 
    {
        ...
    }
}

exactement la même chose que ça :

internal class MyClass
{
    public void DoSomething() 
    {
        lock(this) 
        {
            ...
        }
    }
}

Answer 1

La première méthode est préférable parce que vous pouvez (et devriez) faire _syncRoot privé. Cela réduit le risque de blocage.

El MethodImplOptions.Synchronized est un reliquat d'une idée ambitieuse antérieure qui s'est avérée ne pas être si bonne après tout.

Concernant la dernière question : Oui, selon ce blog ils sont fonctionnellement équivalents (mais pas mis en œuvre de la même manière). Et toutes les formes de lock(this) sont déconseillés, toujours en raison des scénarios de blocage.

Answer 2

Vérifier http://blogs.msdn.com/b/bclteam/archive/2004/01/20/60719.aspx et http://www.experts-exchange.com/Programming/Languages/C_Sharp/Q_20926988.html
Ils discutent de lock(this) aussi et déconseille de l'utiliser depuis :

un code complètement indépendant peut choisir de se verrouiller sur cet objet également.

Citation de EE :

Si vous verrouillez un objet, tous les autres threads qui doivent accéder à CET OBJET PARTICULIER attendront, jusqu'à ce que l'autre objet ait terminé. En revanche, si vous marquez une méthode comme étant Synchronisée, CETTE MÉTHODE PARTICULIÈRE ne sera pas exécutée par plus d'un thread. Lock sécurise l'objet, Synchronized sécurise la méthode.

Answer 3

J'ai jeté un coup d'œil rapide et j'ai constaté que les dispositifs portables ne prennent pas en charge MethodImplOptions.Synchronized.

Il y a aussi une remarque :

Le verrouillage sur l'instance ou sur le type, comme avec l'indicateur Synchronized, n'est pas recommandé pour les types publics, car du code autre que le vôtre peut prendre des verrous sur les types et les instances publiques. Cela peut provoquer des blocages ou d'autres problèmes de synchronisation.

source : http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions%28v=VS.100%29.aspx

Answer 4

Je pense que la différence dépendrait des objets référencés dans les méthodes décorées. D'après ce que j'ai lu, la décoration implémente en fait lock() en IL.

La meilleure approche serait d'effectuer le verrouillage le plus spécifique possible, si nécessaire.

Answer 5

Cet article peut vous aider : http://www.yoda.arachsys.com/csharp/threads/lockchoice.shtml

En général, j'éviterais de verrouiller sur 'this', car les variables de verrouillage privées offrent un meilleur contrôle. Je recommanderais de verrouiller sur 'this', s'il s'agit d'une classe de collection personnalisée, quelque chose du type SyncRoot, si c'est ce qui est requis.

Hasanain