Terioa Watki Komunikacja

0

Pytanie!!Skąd watek w1 wie ze wątek w2 ( albo odwrotnie ) wykonuje właśnie fragment kodu synchronized(this)
{
//jakis kod
}
:-(

Przyklad:
public class watki_static {
static double a[];
static double sum;

static class watek extends Thread
{
double suma;
int x,y;
watek(int n ,int m)
{
this.x=n;
this.y=m;
}
public void run()
{
for(int i=x;i<y;i++)
{
suma+=a[i];
}
synchronized(this){
sum+=suma;
}
System.out.println("Watek " + suma);
}

}

/**

  • @param args the command line arguments
    */
    public static void main(String[] args)
    {
    a=new double[]{1,2,3,4,5,6};
    watek w1=new watek(0,3);
    watek w2=new watek(3,6);

    w1.start();
    w2.start();
    try
    {
    w1.join();
    w2.join();
    }catch(InterruptedException e){}
    System.out.println("Wynik " + sum);
    }

}

0
 synchronized(this){
(...)
}

w klasie wątku nic nie daje, bo "this" dla każdego wątku jest inne, więc wątki nie są zsynchronizowane.
Twój kod wypisze jedną z liczb od 1 do 21, ale nie wiadomo którą. Jeżeli chcesz się o tym przekonać, to użyj bardzo dużej tablicy (np. 10000 elementów).

Musisz podać jakiś singleton, np. watek.class

 synchronized(watek.class){
(...)
}
0

JVM w momencie wejścia wątku w blok synchronized sprawdza czy muteks (czyli obiekt względem którego synchronizujesz) nie jest oznaczony jako zablokowany. JVM przechowuje informacje o blokadzie na poziomie własnego mechanizmu. Wątki nie wiedzą o sobie nic.

Co do wyboru muteksu to są pewne zasady. Muteks musi być niezmiennikiem. Niezmiennik to taki obiekt, który w wyniku wykonania kodu powinien zostać zmieniony w ramach jednej operacji. Muteks musi być dostępny dla wszystkich obiektów. Dlatego też jako muteks nie należy stosować this oraz zmiennych lokalnych.

0

A czy to tez nie jest tak ze za komunikacje miedzy watkami odpowiada również funkcja join() ?? cytuje
"Skąd więc wątek może wiedzieć, że inny wątek się zakończył?
*final boolean isAlive()
*final void join() throws InterruptedException"

0

@kc86, nie do końca. Wątek nie wie o innych wątkach, ale:

  • Inny wątek może zostać przekazany tak jak zwykły obiekt i można na nim działać jak na obiekcie. Dla wątku inny wątek jest zwyczajnym obiektem.
  • Wątek udostępnia metody nasłuchujące takie jak isAlive(), join() czy interrupt(), ale nie wie nic o tym kto je wywołuje.

Wiele metod działa na zasadzie świateł ulicznych. Wykonujesz ich polecenia nie wnikając kto nimi steruje. Trochę jak Pies Pawłowa.

0

Kazdy obiekt ma monior?? tak przynajmnei czytalem w wykladach itp. ale gdy dzis mnie profesor pyta o te watki i synchronizacje to mi mowi ze gdyby kazdy obiekt mial monitor to by nie bylo synchronizacji ( cso bełkotał że synchronizacja jest dzieki static klasa statycznym ich własciwoscia ) o co kaman??

0

Albo nie zrozumiales co mowil wykladowca, albo on sie (solidnie) pomysliil. Tak, w Javie kazdy obiekt jest monitorem, czyli obiektem ktory ma niejawny lock (wg definicji Hoary / Hansena, ktorzy wymyslili to pojecie, wszystkie metody obiektu bedacego monitorem musza byc prywatne, wiec w zasadzie Java nie jest zgodna z definicja w 100%, i byla tez przez w/w panow). Co do statycznych wlasciwosci klasy to poza tym ze rowniez sa to obiekty (lub prymitywy, pomijamy w dyskusji) i co za tym idzie sa monitorami, mozna na nich synchronizowac. Poza widocznoscia tych monitorow, nie zmieniaja one nic jesli chodzi o synchronizacje.

  • i byla tez przez w/w panow krytykowana

Moderatora prosze o sklejenie tych wypowiedzi :-)

0

Podsumujmy:
-każdy obiekt jest monitorem
-klasa jest obiektem
-aby dwa wątki się wykluczały, muszę się synchronizować na tym samym monitorze

Różnice pomiędzy monitorami z Javy i klasycznymi:
-w Javie z każdym monitorem związana jest dokładnie jedna zmienna Condition (można na nim zrobić wait() i notify()). W klasycznych monitorach można mieć dowolnie dużo zmiennych Condition dla jednego monitora. W Javie jest specjalna klasa ReentrantLock, która to umożliwia.
-wywołanie notify() nie odkłada aktualnego wątku na stos
-po wywołaniu notify() obudzony wątek nie dziedziczy automatycznie sekcji krytycznej

0

Klasa nie jest obiektem, klasa jest typem, obiektem sa isntancje klasy.
Kazdy monitor ma tylko 1 lock. Condition, ReentrantLock i reszta to jest wysokopoziomiowa implementacja prymitywow synchronizacji z poziomu jezyka. Nie ma zupelnie nic wspolnego z blokami synchronized, jest analogiczna.
O tych stosach, nie czaje za wiele, domyslam sie o co moze chodzic, ale nie tedy droga.

0
eciepecie napisał(a)

Klasa nie jest obiektem, klasa jest typem, obiektem sa isntancje klasy.

Klasa (np. Object.class) jest obiektem.

eciepecie napisał(a)

Kazdy monitor ma tylko 1 lock. Condition, ReentrantLock i reszta to jest wysokopoziomiowa implementacja prymitywow synchronizacji z poziomu jezyka. Nie ma zupelnie nic wspolnego z blokami synchronized, jest analogiczna.

Klasyczny (opracowany przez Hoare'a i Hansena) monitor może mieć wiele zmiennych warunkowych.
ReentrantLock to też monitor, ale nie ma nic wspólnego z blokiem synchronizowanym (wystarczy spojrzeć w źródła, aby przekonać się, że wewnętrznie nigdzie nie używa "synchronized").

Cytat z dokumentacji ReentrantLock:

A reentrant mutual exclusion Lock with the same basic behavior and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.

eciepecie napisał(a)

O tych stosach, nie czaje za wiele, domyslam sie o co moze chodzic, ale nie tedy droga.

Klasyczny monitor używa stosu do zawieszania i wznawiania wątków, które wykonały signal() jeżeli nie była to ostatnia instrukcja w monitorze. Po wykonaniu signal() następuje przekazanie sekcji krytycznej.
W Javie jednak ani blok synchronizowany, ani ReentrantLock nie mają takiego mechanizmu.

0

...

0

Klasa nie jest obiektem, Object.class to instancja typu (klasy) Class<Object>, a to zupelnie co innego.
ReentrantLock nie jest monitorem, obiekty klasy ReentrantLock sa, oraz ReentrantLock.class jest, ale tylko dlatego ze maja niejawne monitory javy tak jak wszystkie obiekty. Uzywajac klasy ReentrantLock nie uzywa sie (w zamysle tworcow klasy) blokow synchronized, metod wait() notify() (nalezace do klasy Object), tylko signal() i await() nalezace do ReentrantLock. Blok synchronized zastepuje sie:
Lock lock = ...;
lock.lock();
try {
// do stuff
} finally {
lock.unlock();
}
Aha, no i profesor nie zawsze ma racje, bo oprocz tego ze jest profesorem jest tez czlowiekiem, najczesciej dosc starym. Ale koncze swoje wywody ;-)

0

Widzę, że w zasadzie kłócimy się o kwestie nazewnicze.

Ja "Object.class" nazywam klasą. Może to rzeczywiście skrót myślowy.
Natomiast "monitor" to dla mnie abstrakcyjny mechanizm zaproponowany przez Hoare'a i Hansen'a.
Bloki synchronizowane oraz ReentrantLock + Condition (metody lock, unlock, signal i await) uważam za pewne implementacje tego abstrakcyjnego mechanizmu.

1 użytkowników online, w tym zalogowanych: 0, gości: 1