J'ai besoin de créer un Thread-safe variable statique en C# .Net

ok, il est un peu plus compliqué que la question.

class A
{
   static int needsToBeThreadSafe = 0;

   public static void M1()
   {
     needsToBeThreadSafe = RandomNumber();
   }

   public static void M2()
   {
     print(needsToBeThreadSafe);
   }
}

maintenant j'ai besoin que entre M1() et M2() appelle " needsToBeThreadSafe séjour Thread-Safe.

Vous voulez dire que vous souhaitez que les appels à M1() et M2() atomique?
Qu'entendez-vous par "reste" thread-safe"?

OriginalL'auteur Storm | 2009-08-10

c#static thread-safety

19

Ce que vous pouvez essayer de demander à propos de la [ThreadStatic] attribut. Si vous souhaitez que chaque thread qui utilise la classe A d'avoir sa propre valeur de needsToBeThreadSafe ensuite vous avez juste besoin de décorer ce domaine avec l' [ThreadStatic] attribut.

Pour plus d'informations, reportez-vous à la La documentation MSDN pour ThreadStaticAttribute.

Je suppose que tout le monde a aussi le droit, mais pour ma situation, cela fonctionne parfaitement.
OK, mais ThreadStatic est autre chose que des Threads.
En quelque sorte, je viens de réaliser que ce qu'il est vraiment après est une valeur qui n'est pas partagé entre les Threads. En outre, ThreadStatic thread-safe depuis effectivement pas de deux threads accèdent à la même variable (même si on dirait qu'ils sont).
Bon travail sur la réponse à la question, mais en éliminant le risque de conflit en créant des copies locales signifie que c'est, par définition, n'est pas "thread-safe". Même s'il n'est pas "dangereux", le fil de sécurité signifie qu'il gère correctement plusieurs threads traitant avec le ressource, je ne dirais pas que la copie de la ressource est un moyen de le faire.
J' ne obtenir vos points et je ne veux pas prolonger inutilement la conversation, mais ma compréhension de "thread-safe" si un morceau de code est sûr d'exécuter simultanément sous plusieurs threads. "Thread local storage" est une banale mise en œuvre de cette définition et ne pourrait pas répondre à vos besoins si vous avez réellement besoin de données partagée. Si ce que vous avez besoin est de plusieurs threads d'exécution sans fils marcher sur les pieds des autres, et "thread local storage" répond à vos besoins, alors c'est le chemin à parcourir. En outre, l'article de Wikipedia (en.wikipedia.org/wiki/Thread_safety) semble d'accord avec moi.

OriginalL'auteur paracycle

Comment Sur:

public static void M1()
{
    Interlocked.Exchange( ref needsToBeThreadSafe, RandomNumber() );
}

public static void M2()
{
    print( Interlocked.Read( ref needsToBeThreadSafe ) );
}

J'ADORE celle-là, est sûr et est super rapide, dommage qu'il ai que 4 upvotes (le mien compris) après la moitié de la décennie!

OriginalL'auteur cosmo

8

Vous avez deux choix: le plus simple étant donné votre code présenté est le volatile mot-clé. déclarer needsToBeThreadSafe comme static volatile int et qui va garantir que n'importe quel thread qui fait référence à cette variable permettra d'obtenir la "dernière" de la copie, et la variable ne sera pas mis en cache dans votre code.

Cela étant dit, si vous voulez, plus généralement, s'assurer que M1() et M2() exécuter "croisé" (ou au moins exclusivement les uns des autres), alors vous voulez utiliser un lock. Le plus propre syntaxe est avec un "verrouillage de bloc", comme ceci:
```
private static object locker = new Object();

//..

public static void M1()
{
    lock(locker)
    {
        //..method body here
    }
}

public static void M2()
{
    lock(locker)
    {
        //..method body here
    }
}
```
Qui approche à prendre, c'est à vous et doivent être déterminés par le code. Si vous avez besoin pour s'assurer qu'un membre d'affectation obtient propagée à tous les fils et n'est pas mis en cache, le volatile mot-clé est plus simple et faire le travail tout aussi bien. Si c'est au-delà de cela, vous pouvez aller avec la lock.

petite armoire doit être readonly, qu'une précaution...

OriginalL'auteur Adam Robinson

class A
{
   static int needsToBeThreadSafe = 0;
   static object statObjLocker = new object();

   public static void M1()
   {
       lock(statObjLocker)
       {
          needsToBeThreadSafe = RandomNumber();
       }
   }

   public static void M2()
   {
       lock(statObjLocker)
       {
          print(needsToBeThreadSafe);
       }
   }
}

statObjLocker doit être readonly, qu'une précaution...

OriginalL'auteur Arsen Mkrtchyan

2

Son comme vous avez besoin d'un Volatile membre.
```
static volatile int needsToBeThreadSafe = 0;
```
Il était 2009, commentaire, mais de nos jours, il est préférable d'éviter volatile, car il a des effets secondaires...

OriginalL'auteur C. Ross

Vous pouvez également utiliser le ReaderWriterLockSlim, qui est plus efficace pour de multiples lectures et moins écrit:

static int needsToBeThreadSafe = 0;
static System.Threading.ReaderWriterLockSlim rwl = new System.Threading.ReaderWriterLockSlim();

public static void M1()
{
    try
    {
        rwl.EnterWriteLock();
        needsToBeThreadSafe = RandomNumber();
    }
    finally
    {
        rwl.ExitWriteLock();
    }

}

public static void M2()
{
    try
    {
        rwl.EnterReadLock();
        print(needsToBeThreadSafe);
    }
    finally
    {
        rwl.ExitReadLock();
    }
}

rwl doit être readonly, qu'une précaution...

OriginalL'auteur HuBeZa

2

Pour commencer je suis d'accord avec les réponses à l'aide de lock(), c'est la manière la plus sûre.

Mais il en existe une plus approche minimaliste, votre exemple de code ne montre que seule instructions à l'aide de needsToBeThreadSafe et depuis int est atomique, vous avez seulement besoin d'empêcher la mise en cache par le compilateur à l'aide de volatile:
```
class A
{
   static volatile int needsToBeThreadSafe = 0;

}
```
Mais si vous avez besoin d'needsToBeThreadSafe être "thread-safe" sur plusieurs états, l'utilisation d'un verrou.

C'était en 2009 de réponse, mais aujourd'hui, il serait préférable d'utiliser en réponse a suggéré de verrouillage de volatiles, alors que la volatilité a des effets secondaires, qui ont tendance à créer des problèmes...

OriginalL'auteur Henk Holterman

Vous devez vous connecter pour publier un commentaire.