[.NET] Thread-safety en static member variables?

[MrBucket]

Ik hoop dat jullie helderheid kunnen verschaffen over het volgende.

Als ik in de documentatie kijk van de meeste classes van de CLR, zie ik daar staan: "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe."

Hoe moet dit ik dit nu lezen? Voor zover ik weet zijn static member variabelen van zo'n type niet per definitie thread-safe, omdat ze nog steeds door meerdere threads tegelijk benaderd kunnen worden. Maar als ze in de implementatie van zo'n klasse rekening houden met thread-safety (m.a.w.: er worden mutexen of monitors gebruikt), waarom zijn instance member variabelen van zo'n type dan niet ook thread-safe?

[Verwijderd]

MrBucket schreef op zondag 15 januari 2006 @ 20:07:

Hoe moet dit ik dit nu lezen? Voor zover ik weet zijn static member variabelen van zo'n type niet per definitie thread-safe, omdat ze nog steeds door meerdere threads tegelijk benaderd kunnen worden.

Heb je dat getest dan? Als er staat dat een static member var van zo'n type thread safe is, zal dat ook wel zo zijn toch ?

[MrBucket]

Het zal ook echt wel kloppen, maar het gaat mij erom of die thread-safety nu toch komt door het feit dat het een static member variable betreft, of dat ze per class speciale maatregelen hebben genomen waardoor alleen static member variabelen thread-safe zijn.

[whoami]

Wellicht vind je dit interessant
klik

Waarom zou MS er trouwens voor zorgen om alle members per definitie thread-safe te maken ? Als je iets 'thread-safe' maakt mbhv locks etc... dan heeft dat toch ook een invloed op de performantie, terwijl je in bepaalde gevallen die thread-safety helemaal niet nodig hebt.
Als je toch een thread-safe instantie wilt van een instance, dan kan je die verkrijgen door de Synchronized method aan te roepen.

Echter, geldt die opmerking in de MS documentatie voor de static member variablen, of voor de static member methods ?
Een static member method kan thread-safe geimplementeerd worden zonder gebruik te maken van locks/mutexes, etc... (zie artikel).

Dit vind je wellicht ook interessant.

Een static member variable zal thread-safe gemaakt zijn, omdat die niet gebonden is aan een instance, maar aan het type. Iedere instantie van een bepaald type, benadert dezelfde static variable.
Een static member variable wordt blijkbaar op deze manier 'thread safe' gemaakt.

code:

class Melp
{
    public static DateTime Bliep;

    public static void SetBliep()
    {
          lock( typeof(Melp) )
          {
               Bliep = DateTime.Now;
          }
    }
}

[ Voor 162% gewijzigd door whoami op 15-01-2006 21:03 ]

[Zr40]

whoami schreef op zondag 15 januari 2006 @ 20:41:
Een static member variable wordt blijkbaar op deze manier 'thread safe' gemaakt.

code:

class Melp
{
    public static DateTime Bliep;

    public static void SetBliep()
    {
          lock( typeof(Melp) )
          {
               Bliep = DateTime.Now;
          }
    }
}

Nee, dat maakt SetBliep thread-safe. Als je Bliep thread-safe wil benaderen Als je wilt dat Bliep altijd thread-safe benaderd wordt, kan je dit doen:

C#:

class Melp
{
    public static volatile DateTime Bliep;

    public static void SetBliep()
    {
        Bliep = DateTime.Now;
    }
}

[ Voor 6% gewijzigd door Zr40 op 16-01-2006 09:30 . Reden: Uitleg verduidelijkt ]

[whoami]

Ik bedoelde dat Bliep in SetBliep thread-safe benaderd werd.

[Zr40]

Dat klopt, maar dat gebeurt binnen SetBliep(). Bliep zelf wordt er niet automagisch thread-safe van. Omdat Bliep public is, is het belangrijk hier een onderscheid tussen te maken.

[MrBucket]

Thanks voor de links, ik snap nu wat ze met de betreffende zin bedoelen. Blijkbaar heb ik de zin al die tijd verkeerd geinterpreteerd;

Ik dacht nl. het volgende:
Als je een String object hebt, en je kent deze toe aan een static variabele, dan zijn alle methoden van deze String thread-safe. Ken je dit object toe aan een instance variabele, dan is de string niet thread-safe.
Deze gedachte was dus fout.

Het moest zijn:
Als je een String-object hebt, zijn alle static methoden en fields van die String thread-safe, de rest niet.

Hardstikke bedankt jongens

[H!GHGuY]

whoami schreef op zondag 15 januari 2006 @ 20:41:
Een static member variable wordt blijkbaar op deze manier 'thread safe' gemaakt.

code:

class Melp
{
    public static DateTime Bliep;

    public static void SetBliep()
    {
          lock( typeof(Melp) )
          {
               Bliep = DateTime.Now;
          }
    }
}

en volgens dit artikel is dat bad practice.

C#:

class MyClass
{
  static volatile int myInt;
  static object staticlocker = new object();

  static void setInt(int a)
  {
     lock(staticlocker)
        myInt = a;
  }
}

(hence ook de _SyncRoot bij veel classes)

bovendien bevat die URL die ik je gaf een hele mooie tutorial over hoe je op een goeie en mooie manier multi-threading implementeert. ik heb er alleszins enkele bad practices door afgeleerd.

[ Voor 4% gewijzigd door H!GHGuY op 16-01-2006 10:01 ]

[Soultaker]

De TS is er blijkbaar uit, maar ik begrijp er nog steeds geen bal van.

Wat bedoelt Microsoft met het 'thread safe zijn' van een variabele?

[.oisyn]

MS bedoelt niets met variabelen, MrBucket had het verkeerd geinterpreteerd. Er stond dat de public static members van die class allemaal threadsafe zijn, maar daar zitten geen variabelen tussen; alleen methods en/of properties.

[Zr40]

Soultaker schreef op maandag 16 januari 2006 @ 10:52:
De TS is er blijkbaar uit, maar ik begrijp er nog steeds geen bal van.

Wat bedoelt Microsoft met het 'thread safe zijn' van een variabele?

Niet variable, maar method.

Stel, je hebt twee threads, die beiden met hetzelfde object werken. Als thread 1 twee variabelen in dat object aanpast, en thread 2 die twee uitleest, is het mogelijk dat thread 2 leest terwijl thread 1 nog aan het schrijven is. Thread 2 leest dan bijvoorbeeld de nieuwe inhoud van de ene variabele, maar de oude inhoud van de andere variabele.
Erger is het als de twee threads tegelijk schrijven. Als thread 2 schrijft terwijl 1 nog bezig is, kan een deel van het object de data van de ene thread bevatten, en het andere deel van de andere thread. Resultaat: ongeldige data.

Als je je methods thread-safe maakt, zorg je ervoor dat de twee threads nooit tegelijk schrijven. Dit doe je met het lock statement.

Wat Microsoft bedoelt met het thread-safe zijn van static methods, is dat ze de betreffende methods thread-safe gemaakt hebben.

[ Voor 13% gewijzigd door Zr40 op 16-01-2006 11:38 ]

[Soultaker]

Ach zo, inderdaad niets met variabelen; ik was ook op het verkeerde been gezet door de voorbeelden in het topic. (Ik neem aan dat .NET als Java wel garandeerd dat reads/writes in principe atomair zijn; dwz. je kunt nooit een 'kapotte' object reference krijgen door een synchronisatieprobleem).

@Zr40: bedankt voor de uitleg over thread safety, maar op zich was dat niet het punt waar ik over struikelde.