Hejsa. Thread safe

try {
  Monitor.Enter(x);

  [Synchronized stuff]

}finally{
  Monitor.Exit(x);
}

/B :)

men monitor er jo også en library funktion eller?

Joeh.. Den ligger i System.Threading namespace't og er der med en del af .NET class-library'et. Men altså - jeg ser ikke lige rationalet i dit spørgsmål. Er der nogen grund til, at du ikke vil bruge de synkroniseringsmetoder som sproget stiller til rådighed?

/B :)

hehe nej, kan godt forstå du undrer dig...men det gør jeg også - er bare nysgerrig efter at vide hvordan DE har implementeret library funktionen. Har haft en del teori om emnet, og bl.a. atomic actions som vel er kerneni problemet - læs og sæt adgangs-variabel i én instruktion. Men hvordan gør man så det? Eksempler i andet end C# modtages også gerne :)

lock bliver oversat til et kald til Monitor.Enter af compileren.

Monitor.Enter er igen implementeret ved at kalde operativsystemets implementation af synkronisering http://msdn2.microsoft.com/en-us/library/ms686360(VS.85).aspx, specifikt mener jeg at http://msdn2.microsoft.com/en-us/library/ms687028(VS.85).aspx anvendes.

Så kan man spørge sig selv, hvordan denne funktion er implementeret. Det kan gøres på forskellige måder, men nøglen her er at det er implementeret på OS niveau, og der derfor er et helt andet niveau af kontrol med, hvilken tråd der er aktiv, mm.

Jeg er ikke videre inde i, hvilken algoritme, der specifikt bruges i f.ek.s Windows - men man kan finde forklaringer på nogle algoritmer til formålet på Google:
http://www.google.dk/search?q=os+implementing+synchronization&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

En let måde at gøre en type thread safe er ved at lave den immutable som det f.eks. er tilfældet med String. Det vil sige, at hver gang du ville ændre tilstanden, laver du et nyt objekt. Det har selvfølgelig sine omkostninger, men det er thread safe.

Derudover er lock (som bliver til Monitor.Enter/Exit) svaret i de fleste tilfælde. Til mindre ting kan du bruge Interlocked. Der er også adgang til de andre synkroniseringsprimitiver i Windows, men de performer noget dårligere pga springet til native kode.

Brian

Tak for input allesammen! :)