[es] - lock Statement ... pomoc oko razumevanja

JedanDvaTri
student

Član broj: 222386
Poruke: 21
77.46.188.*

Profil

lock Statement ... pomoc oko razumevanja

^{24.10.2009. u 15:56 - pre 176 meseci}

Na drugom primeru je pokusaj da se objasni lock statement.Jasno mi je da je lock statement zaduzen za zakljucavanje dela koda , da bih obezbedili da samo jedna nit "dira" dati resurs u jednom trenutku vremena (to jest dok je u lock bloku). To je jasno,ali mi sintaksa nije jasna. Zasto pisati (kao u prvom primeru) lock za neki objekat koji nigde nema referencu, osim u lock statementu??? Cemu to ? Radi kozmetike? Jasnije bi bilo da sintaksa radi nesto tipa : lock(balance){ //nesto } (posto u sustini necemo da nam balance promenljivu neko dira, gledajuci drugi primer), ali lock radi samo na referentnim tipovima.... pa to ne moze da radi. Nista tu ne razumem, ali apsolutno nista. Koji je mozak smisljao takvu sintaksu....

Hteo bih da zamolim nekog da mi objasni ove nedoumice.
Hvala vam unapred.

Code:

lock (thisLock)
{

//pa nesto

}

Code:

// using System.Threading;

class Account
{
    private Object thisLock = new Object();
    int balance;

    Random r = new Random();

    public Account(int initial)
    {
        balance = initial;
    }

    int Withdraw(int amount)
    {

        // This condition will never be true unless the lock statement
        // is commented out:
        if (balance < 0)
        {
            throw new Exception("Negative Balance");
        }

        // Comment out the next line to see the effect of leaving out
        // the lock keyword:
        lock (thisLock)
        {
            if (balance >= amount)
            {
                Console.WriteLine("Balance before Withdrawal :  " + balance);
                Console.WriteLine("Amount to Withdraw        : -" + amount);
                balance = balance - amount;
                Console.WriteLine("Balance after Withdrawal  :  " + balance);
                return amount;
            }
            else
            {
                return 0; // transaction rejected
            }
        }
    }

    public void DoTransactions()
    {
        for (int i = 0; i < 100; i++)
        {
            Withdraw(r.Next(1, 100));
        }
    }
}

class Test
{
    static void Main()
    {
        Thread[] threads = new Thread[10];
        Account acc = new Account(1000);
        for (int i = 0; i < 10; i++)
        {
            Thread t = new Thread(new ThreadStart(acc.DoTransactions));
            threads[i] = t;
        }
        for (int i = 0; i < 10; i++)
        {
            threads[i].Start();
        }
    }
}

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: lock Statement ... pomoc oko razumevanja

^{24.10.2009. u 22:47 - pre 176 meseci}

Ok

ne moze lock(balance) zato sto lock zahteva referencu, balance je valuetype tipa (int)

malo pogresno posmatras sta je lock, lock ne znaci "ulazim u region koda gde stitim taj i taj resurs koji mi je u parametru", to je samo posledica. reference lock-u ne znace nista funckionalno, znace samo kao "markeri" za prepoznavanje da u svojim internim strukturama locira odgovarajuci handle, dok god dva poziva locku imaju isti parametar bice razdvojeni i nece dozvoliti ada dva thread udju u isti region. Kad bi npr umesto lock(thisLock) stavio lock(new object()) lock bi bio beskoristan jer bi svaki poziv locka radio sa razlicitim parametrima i nikad nijedan thread ne bi blokirao.
Sa druge strane kad bi napravio dve isntance Account klase svaka bi imala svoj thisLock i onda bi pozivi unutar jedne istnace blokirali ali ne bi sprecavali pozive u drugoj instanci (koja ima drugi thisLock)

I btw ovaj primer je pisao neko ko nema mnogo iskustva sa konkurentnim programiranjem, nema potrebe da instanciras thisLock samo da bi ga koristio u locku jer je ta instanca 1-1 sa Account instancom, mozes slobodno da izbacis to i koristis lock(this). Drugo, vaznije je da instance metode Random klase nisu garantovane kao thread safe sto znaci da bi dva poziva r.Next() mogla da imaju nezeljene posledice (od generisanja ne-random brojeva do exception-a), po pravilu i poziv r.Next bi mora u lock(this) ili lock(r)

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić

Odgovor na temu

Toxter
NS

Član broj: 39393
Poruke: 317
*.dynamic.sbb.rs.

+6 Profil

Re: lock Statement ... pomoc oko razumevanja

^{24.10.2009. u 23:48 - pre 176 meseci}

lock(this) ?

Ja bih savetovao da se uvek koristi lock(_privateLockObject) jer lock(this) moze biti uzrok potencijalnog deadlock-a.

Pozdrav

Sad mu nije nista, ubio si ga k'o zeca...

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: lock Statement ... pomoc oko razumevanja

^{25.10.2009. u 08:24 - pre 176 meseci}

Za takvo nesto je neophodan dvostruki lock koji ovde namas, drugo cak i da imas deadlock koji bi ti se pojavio je posledica loseg programa i lose paralelizovanog koda, bolje je da testing otkrije deadlock nego da u release ode aplikacija sa funkcionalnim bugom. Ako si u klasi uradio lock(this) a eksterno uradio lock(myAccount) onda se funkcionalno takmicis za isti resurs i uvodjenje privatnog locka je samo stavljanje flastera na ranu i "varanje".

Jedinu konkretnu koristi od internog locka je ako ga deklarises kao property i onda nakacis debager na getter i tako lociras sve lockove iz svih threadova, ali ako to radis onda taj property treba da eksponiras da bi i externi lockeri mogli da ga koriste umesto instance (slicno kao sto ICollection koristi syncRoot).

Odgovor na temu