Grona >> Java >>

synchronized

Java [1242]

Zapisz się

synchronized

Dodaj kartkę Dodaj bana
Powód wlepienia kartki
Wybierz wątek docelowy z listy lub wpisz jego ID

  • Anonim

    problem mam nieco banalny, ale moja niepewność nie daje mi spokoju...

    problem:
    załóżmy, że mamy klasę z np. 5 metodami, z czego 3 są typu synchronized; we wszelkich możliwych źródłach piszą, że jak jakiś wątek dobiera się do tej jednej z metod typu synchronized no to zakładana jest blokada na obiekt omawianej klasy taka, że reszta metod typu synchronized nie może być wywołana przez żaden inny wątek w danej chwili

    cyt. z Sun'a:
    The system associates a unique lock with every instance of synchronized class (class with synchronized method). Whenever control enters a synchronized method, the thread that called the method locks the object whose method has been called. Other threads cannot call a synchronized method on the same object until the object is unlocked.

    pytanie:
    co w takim razie ze "zwykłymi metodami" - czy są blokowane tak samo jak metody synchronizowane, czy pomimo blokady "zwykłe metody" mogą być wywoływane w danej chwili przez inne wątki?

    pytanie2:
    czy jeżeli wątek A wywoła metodę sychronizowaną obiektu X, to czy ten sam wątek może również wywołać inną metodę synchronizowaną obiektu X w czasie kiedy nałożona jest blokada...?
    "Other threads cannot call a synchronized method on the same object until the object is unlocked. " => skoro nie mogą tylko OTHER THREADS to ten jeden wątek A chyba może...przynajmniej tak z tego wynika

  • Koziołek [brat Javowiec]

    1. metody niesynchronizowane są dostępne. Zrób zresztą test. odpal w dwóch wątkach dwie pętle pierwsza niech wywołuje metodę synchronizowaną druga niesynchronizowaną. Popatrz co będzie się działo.
    2. Blokada to para <wątek klasa> w momencie gdy wywołujesz metodę synchronizowaną MV ustawia taką parę wskaźników. Teraz zrób prosty test:
    class A{
    public syncronized void a(){
    System.out.println("a");
    b();
    }
    public syncronized void b(){
    System.out.println("b");
    }
    }
    z metody synchronizowanej a wywołaj metodę synchronizowaną b .

  • spec

    a nie jest to tak, ze metoda synchronized wywolana z zewnatrz blokuje dostep do zmiany stanu obietku innymi metodami a ztym atrybutem dopoki nie wyjdzie z niej?:)

    czyli wszystko co jest ponizej tej metody w drzewie wywolan, bedzie synchronized.

    i tyle, to tylko formalizm i metoda na zapanowanie nad problemami wielowatkowosci ale nadal nie zatrzyma Cie przed wolaniem dwoch odzielnych watkach zwyklych metod na rzecz tego samego obietku:P

    nie wiem nie pisze w Javie ale mam prawo tak myslec.

    najlepiej nie miec stanow wogole(zmiennych mutuable), problem znika z definicji:D

  • Koziołek [brat Javowiec]

    >spec napisał
    >najlepiej nie miec stanow wogole(zmiennych mutuable),
    >problem znika z definicji:D
    >
    Nie zawsze się tak da :)
    Niektóre rzeczy powinny być blokowane. np dostęp do rekordu w bazie danych czy dostęp do pliku :)

  • spec

    wiesz, w sumie to nie jestem za czysto funckjonalnym horrorem:P
    generalnie input-output emulowany podejsciem czysto funckjoanlnym bez zadnych stanow miedzy wywolaniami i efektami ubocznymi, wiec bez juz roznic w jakiej kolejnosci zostana wywalene funckje to juz hardcore.
    wiki->haskell->monads.
    nie sprawdza to sie w premysle napewno, e - commerce wogole.

    no ale co do tematu to synchronizacja dalej to cos co siedzi nie tylko w dostepie do pamieci w VM zwrapowanej w niej w obietky javy, ale tez jak mowisz wszystko, pliki, bazy, caly input output (funckja flush nawet jest prymitwnym przykladem synchronizacji, commit w svnie tyz)

    a program powinen wykonwyac operacje tylko na inpucie i zwracac output nic wiecej, wiec imho nie potrzebne mi takie skomplikowane rzeczy jak obiekty wiecej bo same w sobie zawieraja stany.
    stan powinen siedziec, program powinen je zmieniac w konetekcie innych stanow.
    w javie to osiagnieto po czesci (ale nie bedzie nigdy osiagniete ze wzgl na paradygmat, dodatkwo dalej mozna produkowac "dziwny" kod w javie)
    przez to ze wszystko jest spiete referencja i nie ma kopiowania jak w C++, wiec dalej stany ale juz szerowane.
    ale nie mozna inaczej jesli kod mialby byc czytelny rowniez dla innych oprocz autora, ale fuk dem! nie?; ] no ja mysle.