Terioa Watki Komunikacja

Odpowiedz Nowy wątek
2009-05-26 22:21

Rejestracja: 11 lat temu

Ostatnio: 11 lat temu

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);
    }

}

Pozostało 580 znaków

2009-05-26 22:25

Rejestracja: 13 lat temu

Ostatnio: 4 lata temu

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){
(...)
}

Registered Linux user #456405 | SCJP 6 | SCWCD 5 | SCBCD 5

Pozostało 580 znaków

2009-05-26 22:37
Moderator

Rejestracja: 13 lat temu

Ostatnio: 2 minuty temu

Lokalizacja: Stacktrace

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.


Sięgam tam, gdzie wzrok nie sięga… a tam NullPointerException

Pozostało 580 znaków

2009-05-27 10:55

Rejestracja: 11 lat temu

Ostatnio: 11 lat temu

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"

Pozostało 580 znaków

2009-05-27 11:32
Moderator

Rejestracja: 13 lat temu

Ostatnio: 2 minuty temu

Lokalizacja: Stacktrace

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.


Sięgam tam, gdzie wzrok nie sięga… a tam NullPointerException

Pozostało 580 znaków

2009-05-27 15:04

Rejestracja: 11 lat temu

Ostatnio: 11 lat temu

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??

Pozostało 580 znaków

eciepecie
2009-05-27 18:28
eciepecie
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 :-)

Pozostało 580 znaków

2009-05-27 20:16

Rejestracja: 13 lat temu

Ostatnio: 4 lata temu

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


Registered Linux user #456405 | SCJP 6 | SCWCD 5 | SCBCD 5

Pozostało 580 znaków

eciepecie
2009-05-27 21:03
eciepecie
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.

Pozostało 580 znaków

2009-05-27 21:27

Rejestracja: 13 lat temu

Ostatnio: 4 lata temu

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.


Registered Linux user #456405 | SCJP 6 | SCWCD 5 | SCBCD 5

Pozostało 580 znaków

2009-05-27 21:35

Rejestracja: 11 lat temu

Ostatnio: 11 lat temu

0

...

Pozostało 580 znaków

Odpowiedz

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