🚀 go-pugleaf

W dniu 2010-03-21 17:29, andrzej salwicki pisze:
> Czy można w efektywny sposób zaprogramować wątek A tak by pełnił swoje
> zadanie i równocześnie był gotów świadczyc usługi? Dokładniej, czy
> inne wątki: B, C, ... mogą wywoływać metody publiczne, synchronized
> wątku A, powodując chwilowe przerwanie akcji wątku A,[ciach]

Obawiam się, że mylisz wątek z obiektem.
Wątek B może wykonać metodę x() na rzecz obiektu A (który może, ale nie 
musi być instancją klasy pochodnej po Thread), ale to wywołanie wykona 
się w wątku B, a nie A.

Jeśli chcesz aby wątek B "zlecał" zadania do wykonania wątkowi A, to 
proponuję zainteresować się interfejsem BlokingQueue i implementującymi 
go klasami, albo kolejkami w ogóle. No i wzorcami takimi jak Producer i 
Consumer.

-- 
np

Obawiam się, że pytanie jest zbyt trudne.

Rozważmy klasę Spooler, klasę Klient oraz trzy wątki s, a, b.

class Spooler extends Thread {
    synchronized void drukuj (Plik f) {  }
    void run ( ) { tu w kółko sprawdzamy czy jest cos do drukowania i
drukujemy }
}

Spooler s;
s.start()

class Klient extends Thread {

   void run (0 {
        ....
        call s.drukuj(...);
        ....
   }
}

Klient a,b;
   a= new Klient(Spooler s. ...);  a.start();
   b= new Klient(Spooler s, ...); b.start();

Taki lub podobny schemat chcemy zrealizować. Jak to będzie działać/

=============================================================

On 21 Mar, 18:07, nullpointer <i....@nie.dojdzie.pl> wrote:
> W dniu 2010-03-21 17:29, andrzej salwicki pisze:
>
> > Czy mo na w efektywny spos b zaprogramowa w tek A tak by pe ni swoje
> > zadanie i r wnocze nie by got w wiadczyc us ugi? Dok adniej, czy
> > inne w tki: B, C, ... mog wywo ywa metody publiczne, synchronized
> > w tku A, powoduj c chwilowe przerwanie akcji w tku A,[ciach]
>
> Obawiam si , e mylisz w tek z obiektem.
> W tek B mo e wykona metod x() na rzecz obiektu A (kt ry mo e, ale nie
> musi by instancj klasy pochodnej po Thread), ale to wywo anie wykona
> si w w tku B, a nie A.
>
> Je li chcesz aby w tek B "zleca " zadania do wykonania w tkowi A, to
> proponuj zainteresowa si interfejsem BlokingQueue i implementuj cymi
> go klasami, albo kolejkami w og le. No i wzorcami takimi jak Producer i
> Consumer.
>
> --
> np

W dniu 2010-03-21 18:44, andrzej salwicki pisze:
> Obawiam się, że pytanie jest zbyt trudne.

Przyznaj się raczej, że nie wysiliłeś się, aby poszukać haseł o których 
pisałem...

Cały kod tego co chcesz zrobić znajduje się tutaj:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html

Twój Spooler to Consumer, Twój Klient to Producer.
-- 
np

On Mar 21, 5:29 pm, andrzej salwicki <salwi...@gmail.com> wrote:
> Czy można w efektywny sposób zaprogramować wątek A tak by pełnił swoje
> zadanie i równocześnie był gotów świadczyc usługi? Dokładniej, czy
> inne wątki: B, C, ... mogą wywoływać metody publiczne, synchronized
> wątku A, powodując chwilowe przerwanie akcji wątku A, wykonanie
> wskazanej metody, po czym wątek A kontynuuje swoje obliczenia.

Cześć,

Skłaniałbym się do odpowiedzi pozytywnej, ale zastanawiam się nad
użytym przez Ciebie sformułowaniem "efektywnie" (bo to -
intersubiektywnie - dosyć pojemne określenie ;-)).

Proste rozwiązanie jakie widzę to wprowadzenie do obiektu stanu
modyfikowanego poprzez wywoływanie metod publicznych obiektu i
"sterującego" tym co wykonuje się w ramach metody run(). Bo
oczywiście, wyjście z metody run() skutkuje zakończeniem wątku, więc
"wykonanie" metody obiektu też nie może tego zrobić.

Poniżej przykładowy kod, myślę, że jest dosyć oczywisty, choć zapewne
można uczynić go jeszcze bardziej efektywnym. W Java komunikowanie
wątkowi, że ma coś zrobić (np. zatrzymać się) jest kooperatywne i
zwykle zakłada, że co jakiś czas (= w określonych miejscach kodu)
wątek wykonuje sprawdzenie np. że otrzymał polecenie zatrzymania się i
sam podejmuje decyzję, co z tym zrobić. Potencjalnie, w tym moim
przykładzie, jeśli metoda domyślna (defaultMetoda) wykonywałaby się
długo, to to sprawdzenie czy tryb pracy (mode) jest inny niż domyślny
mogłoby także być wykonywane wewnątrz tej metody, przez co obiekt
szybciej zareagowałby na wykonanie innego niż domyślne zadanie (czyli
szybciej zareagowałby na wywołanie jego metody publicznej z innego
wątku)...
Możnaby też tę metodę drukujMetoda() wykonywać na oddzielnym wątku,
itd...

Przy odrobinie wysiłku (i zastosowaniu paru wzorców projektowych)
możnaby też ten kod uczynić bardziej generycznym i wymagającym mniej
modyfikacji przy dodawaniu kolejnych metod...


\\-------- SPOOLER ---------

package pl.waldekkot;

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.atomic.AtomicInteger;

public class Spooler extends Thread {
	private enum Modes { DEFAULT, DRUKUJ };

	private AtomicInteger mode = new
AtomicInteger(Modes.DEFAULT.ordinal());
	private BlockingQueue<String> queueDrukuj = new
LinkedBlockingQueue<String>();

	public synchronized void drukuj(String x) {
		try {
			this.queueDrukuj.put(x);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}

		this.mode.set(Modes.DRUKUJ.ordinal());
	}

	@Override
	public void run() {
		int i = 0;
		while( true ) {
			switch (Modes.values()[this.mode.get()]) {
				case DRUKUJ:
					try {
						drukujMetoda(this.queueDrukuj.take());
					} catch (InterruptedException e1) {
						e1.printStackTrace();
					}
					this.mode.set(Modes.DEFAULT.ordinal());
					break;

				default:
					if(this.queueDrukuj.size() > 0) {
						this.mode.set(Modes.DRUKUJ.ordinal());
					} else {
						defaultMetoda(i);
						i++;
					}
					break;
			}
		}
	}

	private void drukujMetoda(String x) {
		System.out.println("wykonuje metode drukuj z parametrem: " + x);
	}

	private void defaultMetoda(int i) {
		System.out.println("wykonuje metode default z parametrem: " + i);
	}
}


\\-------- KLIENT ---------
package pl.waldekkot;

public class Klient extends Thread {
	private Spooler s;
	private String msg;

	public Klient(Spooler s, String msg) {
		this.s = s;
		this.msg = msg;
	}

	@Override
	public void run() {
		for(int i = 0; i < 10; i++) {
			this.s.drukuj(msg + " " + i);
		}
	}
}


\\--------- TEST ----------
package pl.waldekkot;

public class ThreadExample {

	public static void main(String[] args) throws InterruptedException {
		Spooler s = new Spooler();
		Klient k1;
		Klient k2;

		s.start();

		k1 = new Klient(s, "pierwszy");
		k1.start();

		Thread.sleep(500);

		k2 = new Klient(s, "drugi");
		k2.start();

		Thread.sleep(500);

		k1 = new Klient(s, "pierwszy znowu");
		k1.start();

		Thread.sleep(500);

		k2 = new Klient(s, "drugi znowu");
		k2.start();

		Thread.sleep(5000);
	}
}

Pozdrawiam,
Waldek Kot

Dziękuję za sugestie (nullpointer i Waldek Kot)

Te rozwiązania nie satysfakcjonują.

Spooler ma zgadzać się na  świadczenie: usługę typu drukuj przez
prawie cały czas, z wyjątkiem chwili gdy
właśnie wykonuje tę usługę.  Nie chcemy zgubić żadnego zgłoszenia i
nie dopuszczamy do bałaganu w kolejce zgłoszeń.

A więc drukuj ma być w zasadzie metodą publiczną, ale czasami ma być
schowana, private.
Ponadto, wywołanie drukuj z zewnątrz ma zawieszać działanie spoolera.
Czyli znowu dobrze by było by drukuj był private - na chwilę.
To potrafię zrobić.
Jak jednak doprowadzic do przerwania spoolera wtedy gdy jakiś klient
wzywa go do wykonania metody drukuj - nie wcześniej ani póżniej?
Jeśli ktos to wie...





On 21 Mar, 18:44, andrzej salwicki <salwi...@gmail.com> wrote:
> Obawiam się, że pytanie jest zbyt trudne.
>
> Rozważmy klasę Spooler, klasę Klient oraz trzy wątki s, a, b.
>
> class Spooler extends Thread {
>     synchronized void drukuj (Plik f) {  }
>     void run ( ) { tu w kółko sprawdzamy czy jest cos do drukowania i
> drukujemy }
>
> }
>
> Spooler s;
> s.start()
>
> class Klient extends Thread {
>
>    void run (0 {
>         ....
>         call s.drukuj(...);
>         ....
>    }
>
> }
>
> Klient a,b;
>    a= new Klient(Spooler s. ...);  a.start();
>    b= new Klient(Spooler s, ...); b.start();
>
> Taki lub podobny schemat chcemy zrealizować. Jak to będzie działać/
>
> =============================================================
>
> On 21 Mar, 18:07, nullpointer <i....@nie.dojdzie.pl> wrote:
>
> > W dniu 2010-03-21 17:29, andrzej salwicki pisze:
>
> > > Czy mo na w efektywny spos b zaprogramowa w tek A tak by pe ni swoje
> > > zadanie i r wnocze nie by got w wiadczyc us ugi? Dok adniej, czy
> > > inne w tki: B, C, ... mog wywo ywa metody publiczne, synchronized
> > > w tku A, powoduj c chwilowe przerwanie akcji w tku A,[ciach]
>
> > Obawiam si , e mylisz w tek z obiektem.
> > W tek B mo e wykona metod x() na rzecz obiektu A (kt ry mo e, ale nie
> > musi by instancj klasy pochodnej po Thread), ale to wywo anie wykona
> > si w w tku B, a nie A.
>
> > Je li chcesz aby w tek B "zleca " zadania do wykonania w tkowi A, to
> > proponuj zainteresowa si interfejsem BlokingQueue i implementuj cymi
> > go klasami, albo kolejkami w og le. No i wzorcami takimi jak Producer i
> > Consumer.
>
> > --
> > np

andrzej salwicki wrote:
> Spooler ma zgadzać się na  świadczenie: usługę typu drukuj przez
> prawie cały czas, z wyjątkiem chwili gdy
> właśnie wykonuje tę usługę.  Nie chcemy zgubić żadnego zgłoszenia i
> nie dopuszczamy do bałaganu w kolejce zgłoszeń.

Tylko, że istotą spoolera jest właśnie to, że potrafi kolejkować, 
magazynować, etc. zgłoszenia w sytuacji, gdy akurat nie ma wolnych 
zasobów na ich przetworzenie. Inny 'byt' realizuje już ich obsługę.

> A więc drukuj ma być w zasadzie metodą publiczną, ale czasami ma być
> schowana, private.

Czy aby nie mylisz 'metody' z klikalnym menu, które można włączyć/wyłączyć?

To o czym piesz, jest właśnie zaprzeczeniem idei spoolera: akceptowanie 
nowych zgłoszeń tylko wtedy gdy można je obsłużyć _oraz_ nie pozwalamy 
na zgubienie żadnego. Aplikacja/użytkownik sam ma ponawiać próby?

andrzej salwicki wrote:

> Dziękuję za sugestie (nullpointer i Waldek Kot)
> 
> Te rozwiązania nie satysfakcjonują.
> 

Mialem sie powstrzymac, ale tym razem nie wytrzymam.

1. Usenet to nie jest bezplatna pomoc w odrabianiu lekcji. Szukaj leszczy 
gdzie indziej.
2. Idz do biblioteki i sie doksztalc, bo nie rozumiejac i nie rozrozniajac 
pojec "watek" i "obiekt" nie jestes w stanie sformulowac problemu.

> Spooler ma zgadzać się na  świadczenie: usługę typu drukuj przez
> prawie cały czas, z wyjątkiem chwili gdy
> właśnie wykonuje tę usługę.  Nie chcemy zgubić żadnego zgłoszenia i
> nie dopuszczamy do bałaganu w kolejce zgłoszeń.

Do tego nie jest potrzebny zaden watek wystarczy:
class Spooler {
  public synchronized void drukuj(Plik f) {...}
}

> 
> A więc drukuj ma być w zasadzie metodą publiczną, ale czasami ma być
> schowana, private.
> Ponadto, wywołanie drukuj z zewnątrz ma zawieszać działanie spoolera.
> Czyli znowu dobrze by było by drukuj był private - na chwilę.
> To potrafię zrobić.

To mnie zaskoczyles. Ciekawe jak sie robi metode private "na chwile".

> Jak jednak doprowadzic do przerwania spoolera wtedy gdy jakiś klient
> wzywa go do wykonania metody drukuj - nie wcześniej ani póżniej?
> Jeśli ktos to wie...

Skoro w trakcie wykonywania zadania ma nie przyjmowac innych zadan, to po co 
cokolwiek przerywac???

> 
> 
> 
> 
> 
> On 21 Mar, 18:44, andrzej salwicki <salwi...@gmail.com> wrote:
[ciach]

Odpowiadamy pod cytatem, a nie nad - nie zapomnij doczytac o netykiecie.

-- 
Michal

Dnia 22.03.2010 Michal Kleczek <kleku75@gmail.com> napisał/a:

> 1. Usenet to nie jest bezplatna pomoc w odrabianiu lekcji. Szukaj leszczy
> gdzie indziej.

Komu jak komu, ale prof. Andrzejowi Salwickiemu -- o ile dobrze identyfikuję
nazwisko -- nie stawiałbym takich zarzutów.

pozdrawiam,
DJ

W dniu 2010-03-22 23:52, Daniel Janus pisze:
> Dnia 22.03.2010 Michal Kleczek<kleku75@gmail.com>  napisał/a:
>
>> 1. Usenet to nie jest bezplatna pomoc w odrabianiu lekcji. Szukaj leszczy
>> gdzie indziej.
>
> Komu jak komu, ale prof. Andrzejowi Salwickiemu -- o ile dobrze identyfikuję
> nazwisko -- nie stawiałbym takich zarzutów.

No nie, jeśli te pytania pochodzą od byłego profesora MiMUWu, 
prowadzącego tam seminarium dotyczące programowania obiektowego, to ja 
wymiękam.

Tadeusz B. Kopeć

Michal Kleczek wrote:
> 1. Usenet to nie jest bezplatna pomoc w odrabianiu lekcji. Szukaj leszczy 
> gdzie indziej.

Może dużo wiesz i jesteś super programistą javy, ale forma twojej 
odpowiedzi jest protekcjonalna oraz chamska. Na jednym z portali jest 
profil osoby o podobnym imieniu i nazwisku; pisze ona o sobie "jestem 
człowiekiem o szerokich horyzontach". Mam nadzieję, że nie jest to twój 
profil, ponieważ trudno byłoby dopasować powyższą wypowiedź do tych 
przekonań o sobie samym.

kulf0n

kulf0n wrote:

> Michal Kleczek wrote:
>> 1. Usenet to nie jest bezplatna pomoc w odrabianiu lekcji. Szukaj leszczy
>> gdzie indziej.
> 
> Może dużo wiesz i jesteś super programistą javy, ale forma twojej
> odpowiedzi jest protekcjonalna oraz chamska. 

Coz moge odpowiedziec... moze to:
http://catb.org/~esr/faqs/smart-questions.html#not_losing

> Na jednym z portali jest
> profil osoby o podobnym imieniu i nazwisku; pisze ona o sobie "jestem
> człowiekiem o szerokich horyzontach". 

O! To nie ja :) Ja tylko komputery...

-- 
Michal

On Mar 21, 5:29 pm, andrzej salwicki <salwi...@gmail.com> wrote:
> Czy można w efektywny sposób zaprogramować wątek A tak by pełnił swoje
> zadanie i równocześnie był gotów świadczyc usługi? Dokładniej, czy
> inne wątki: B, C, ... mogą wywoływać metody publiczne, synchronized
> wątku A, powodując chwilowe przerwanie akcji wątku A, wykonanie
> wskazanej metody, po czym wątek A kontynuuje swoje obliczenia.
> Mam pewne podejrzenia, ale trudno o tym rozstrzygnąć na podstawie JLS.
> Za odpowiedź, wszytko jedno pozytywną czy negatywną- ale uzasadnioną -
> przeznaczam skrzynkę wina lub ekwiwalent.
> Uzasadnienie:
> W przypadku podpowiedzi pozytywnej należy podać przykład programu. Np
> 'Spooler' - proces rejestruje zgłoszone do druku pliki przy pomocy
> metody 'drukuj(plik)' i równocześnie wysyła już zarejestrowane pliki,
> po kolei do drukarki.
> W przypadku odpowiedzi negatywnej należy podać uzasadnienie,
> niekoniecznie w postaci dowodu, ale jakiś intersubiektywny argument
> jest konieczny bym uwierzył.

Tak już zupełnie podsumowując dyskusję: w Javie takie rozwiązanie o
jakim pisze Andrzej (żeby wątki sobie wzajemnie wchodziły w drogę,
blokowały się w "dziki" sposób) nie ma absolutnie sensu. Przykładowy
Spooler może wyglądać następująco:
jest kolejka - coś w rodzaju tablicy/listy/kolejki z synchronizowanym
dostępem, może to być wspomniana już nieraz BlockingQueue. Jest też
wątek - nazwijmy go usługą, którego zadanie polega na pobieraniu
elementów z wspomnianej listy/kolejki. Tak więc nasz wątek odczytuje z
kolejki wiadomość - jeśli nic w niej nie ma to zawiesza swoje
działanie do momentu, aż coś się w kolejce pojawi. Gdy się pojawi -
"ożywa" i wykonuje zadanie, na przykład drukuje plik, gdy skończy
drukowanie znowu wraca do początku i czeka aż coś się pojawi.
Teraz pozostaje kwestia dostępu do tej usługi z zewnątrz - nic
prostszego, wystarczy uzyskać referencję tej listy/kolejki - tej
samej, której używa nasz wątek i włożyć do niej komunikat/plik/itp.
i... tyle (nasza "usługa" może sama zdefiniować metodę w stylu
"drukuj", a w środku tej metody nic innego jak zapakowanie obiektu do
listy). Jeśli nasza usługa jest zajęta drukowaniem, komunikat sobie
poczeka w kolejce, a jeśli nasza usługa nic nie robi, to weźmie się do
roboty jak tylko komunikat/plik zostanie umieszczony w kolejce. Ot -
cała filozofia. Pozostaje jedynie kwestia owej synchronizacji kolejki
z wątkami - jak wspominano tutaj często - można użyć gotowego
BlockingQueue, można sobie samemu takie coś napisać korzystając z
podstawowych instrukcji/modyfikatorów języka (vide synchronized/
volatile/java.util.concurrent.*/...), jak ktoś jest ciekawy jak działa
BlockingQueue - może sobie zajrzeć w źródła.
Innymi słowy - obiekt, który jest odpowiedzialny za drukowanie -
wykonuje to drukowanie w swoim wątku, ale to nie oznacza, że jego
wszystkie metody są wykonywane w jednym i tym samym wątku - dlatego
nie ma różnicy: czy klient dostaje referencje do listy i umieszcza w
niej komunikat, czy może klient dostaje referencję bezpośrednio do
usługi i wykonuje jej metodę #dodajDoKolejki(komunikat). Ważne jest
tylko odpowiednie synchronizowanie (mediacja pomiędzy różnymi wątkami)
- coś co BlockingQueue ma "out of the box", dlatego nazwa tej klasy
cieszy się w tym wątku taką popularnością :)

W dniu 2010-03-21 18:07, nullpointer pisze:
> W dniu 2010-03-21 17:29, andrzej salwicki pisze:
>> Czy można w efektywny sposób zaprogramować wątek A tak by pełnił swoje
>> zadanie i równocześnie był gotów świadczyc usługi? Dokładniej, czy
>> inne wątki: B, C, ... mogą wywoływać metody publiczne, synchronized
>> wątku A, powodując chwilowe przerwanie akcji wątku A,[ciach]
>
> Obawiam się, że mylisz wątek z obiektem.
> Wątek B może wykonać metodę x() na rzecz obiektu A (który może, ale nie
> musi być instancją klasy pochodnej po Thread), ale to wywołanie wykona
> się w wątku B, a nie A.
>
> Jeśli chcesz aby wątek B "zlecał" zadania do wykonania wątkowi A, to
> proponuję zainteresować się interfejsem BlokingQueue i implementującymi
> go klasami, albo kolejkami w ogóle. No i wzorcami takimi jak Producer i
> Consumer.
>

Ja tutaj muszę się zgodzić.

Najważniejszy w Javie (przynajmniej dla mnie) jest interfejs. On określa 
CO będzie zrobione (np. informuje, że może coś posortować). Natomiast 
nie mówi JAK - to robi klasa - dostarcza implementację.

Weźmy przykład:
public interface Sorter{
	public void sort() throws SorterException;
}

Gdzie tu jest napisane JAK elementy są sortowane? Nigdzie. Weźmy 
implementacje (przykładowe dwie)

public class ThreadedSorter implements Sorter{
	public void sort() throws SorterException{
//tworzy wątek i sortuje elementy w osobnym wątku;
}

oraz

public class SimpledSorter implements Sorter{
	public void sort() throws SorterException{
//sortuje elementy w obecnym wątku
}


Z interfejsu (jeśli oczywiście nie jest to napisane explicite), nie 
wynika JAK trzeba coś zrobić.

Teraz pytanie:
Jeśli wątek jest 'pracownikiem', który może zostać całkowicie ukryty - 
klasa używająca obiektu nawet nie musi wiedzieć, że za interfejsem chowa 
się wątek - to czy dobrze jest go 'łączyć' na stałe z klasą, w taki 
sposób, aby WSZYSCY widzieli, że tam jest osobny wątek?

O co mi chodzi?

Dlaczego pisać "extends Thread" lub nawet (w publicznej klasie) 
"implements Runnable", kiedy jest to szczegół implementacyjny, o którym 
klienci mogą nie wiedzieć?

Oczywiście można się kłócić (nawet trzeba :-) ).

Na poparcie moich wypocin, mogę przedstawić interfejs(y):
1. Executor (i ExecutorService), których zadaniem jest ukrywanie wątków
2. Interfejs Runnable, który powinien być używany ZAMIAST dziedziczenia 
po klasie Thread (próba rozdzielenia implementacji od specyfikacji)

I teraz dochodzimy do zasadniczej kwestii. Jak wydzielić interfejs, 
który przedstawia postawiony problem w sposób niezależny od wątków? Da 
się? A jak się nie da, to pytanie brzmi dlaczego? Być może problem leży 
w koncepcji...

Pozdrawiam
keef

On Mar 25, 5:38 pm, keef <a...@a.com> wrote:
> Teraz pytanie:
> Jeśli wątek jest 'pracownikiem', który może zostać całkowicie ukryty -
> klasa używająca obiektu nawet nie musi wiedzieć, że za interfejsem chowa
> się wątek - to czy dobrze jest go 'łączyć' na stałe z klasą, w taki
> sposób, aby WSZYSCY widzieli, że tam jest osobny wątek?

Dobrze kombinujesz, to nie jest dobry pomysł, aby cokolwiek
dziedziczyć bez powodu.

> O co mi chodzi?
>
> Dlaczego pisać "extends Thread" lub nawet (w publicznej klasie)
> "implements Runnable", kiedy jest to szczegół implementacyjny, o którym
> klienci mogą nie wiedzieć?

Zauważ, że można zrobić "...extends Thread implements Cośtam..." i
dalej w świat "puścić" ten obiekt jako Cośtam. Nikt nie musi wiedzieć,
że to dziedziczy po Thread, będzie widać tylko metodę/metody z
Cośtam.

> Na poparcie moich wypocin, mogę przedstawić interfejs(y):
> 1. Executor (i ExecutorService), których zadaniem jest ukrywanie wątków

Ich zadaniem nie jest ukrycie wątków tylko odseparowanie spraw
związanaych z uruchamianiem wątków, zarządzeniem pulami wątków itp.
sprawami, a implementacją logiki, która będzie w tych wątkach
odpalana.

> 2. Interfejs Runnable, który powinien być używany ZAMIAST dziedziczenia
> po klasie Thread (próba rozdzielenia implementacji od specyfikacji)

Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
miejscach, łącznie z tymi, które sam w swoim programie człowiek pisze
i od czasu gdy potrzebuje np. opakować metodę w obiekt, żeby można ją
było przekazać jako parametr.

> I teraz dochodzimy do zasadniczej kwestii. Jak wydzielić interfejs,
> który przedstawia postawiony problem w sposób niezależny od wątków? Da
> się? A jak się nie da, to pytanie brzmi dlaczego? Być może problem leży
> w koncepcji...

Nie zawsze można to zrobić, nie zawsze warto to robić, czasami dobrze
jest zostawić wolną rękę implementacjom - w końcu kto powiedział, że
jak implementujemy interfejs to nie możemy dodać coś od siebie i to
udokumentować. Nie zawsze jest tak, że różne implementacje tego samego
interfejsu są wzajemnie wymienne w naszym kodzie - i to dobrze. Weźmy
taki przykład: interfejs Map - możemy mieć obiekt HashMap, ale możemy
mieć też implementację zwracaną przez #Collections.synchronizedMap  -
każdy z nich możemy przedstawić jako Map, ale działają inaczej, a
interfejs Map nic na ten temat nie mówi. Z drugiej strony mamy
interfejs np. BlockingQueue, który jasno wspomina jak to wszystko
powinno działać biorąc pod uwagę wątki.

W dniu 2010-03-25 22:39, Witold Szczerba pisze:
> On Mar 25, 5:38 pm, keef<a...@a.com>  wrote:
>> Teraz pytanie:
>> Jeśli wątek jest 'pracownikiem', który może zostać całkowicie ukryty -
>> klasa używająca obiektu nawet nie musi wiedzieć, że za interfejsem chowa
>> się wątek - to czy dobrze jest go 'łączyć' na stałe z klasą, w taki
>> sposób, aby WSZYSCY widzieli, że tam jest osobny wątek?
>
> Dobrze kombinujesz, to nie jest dobry pomysł, aby cokolwiek
> dziedziczyć bez powodu.
>
>> O co mi chodzi?
>>
>> Dlaczego pisać "extends Thread" lub nawet (w publicznej klasie)
>> "implements Runnable", kiedy jest to szczegół implementacyjny, o którym
>> klienci mogą nie wiedzieć?
>
> Zauważ, że można zrobić "...extends Thread implements Cośtam..." i
> dalej w świat "puścić" ten obiekt jako Cośtam. Nikt nie musi wiedzieć,
> że to dziedziczy po Thread, będzie widać tylko metodę/metody z
> Cośtam.

Chyba powiedziałeś dokładnie to samo co ja...

Pójdę nawet dalej:
public interface AaaFactory{
public Aaa getAaa();
}
public interface Aaa{
public void sort(int[] tab);
}

public class ThreadedAaaFactory{
public Aaa getAaa(){
return new ThreadedAaa();
}
private static class ThreadedAaa implements Aaa(){
public void sort(int[] tab){
//sortuje;
}
}

public static void main(String[] args){
	AaaFactory aaaFactory = new ThreadedAaa();
	Aaa aaa = aaaFactory.getAaa();
}
I nie możesz polegać na tym, że to będzie w osobnym wątku, lub nie... Bo 
nigdy nie wiesz czy obiekt, który dostaniesz z fabryki używa wątku, czy 
nie... Implementacja jest kompletnie schowana za interfejsem Aaa i za 
fabryką (która dostarcza implementacje).
>
>> Na poparcie moich wypocin, mogę przedstawić interfejs(y):
>> 1. Executor (i ExecutorService), których zadaniem jest ukrywanie wątków
>
> Ich zadaniem nie jest ukrycie wątków tylko odseparowanie spraw
> związanaych z uruchamianiem wątków, zarządzeniem pulami wątków itp.
> sprawami, a implementacją logiki, która będzie w tych wątkach
> odpalana.

Czy aby na pewno? A dlaczego nie zrobić w Aaa factory grupowania 
obiektów (poolowania) za pomocą Executora? I zamiast zwracać zawsze "new 
ThreadedAaa()" pobierać obiekt z puli (oczywiście trzeba rozszerzyć 
interfejs Aaa). I wtedy sposób działania znów jest schowany? A co z 
implementacją, gdy wiele obiektów korzysta z tego samego wątku 
(kolejka)? Również klienty klasy Aaa nie muszą tego wiedzieć. Interfejs 
mówi CO, a nie JAK. Jeśli wybraliśmy taką implementacje, to będzie nam 
to w określony sposób działać (ale zawsze będzie robić to samo)...

>
>> 2. Interfejs Runnable, który powinien być używany ZAMIAST dziedziczenia
>> po klasie Thread (próba rozdzielenia implementacji od specyfikacji)
>
> Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
> miejscach, łącznie z tymi, które sam w swoim programie człowiek pisze
> i od czasu gdy potrzebuje np. opakować metodę w obiekt, żeby można ją
> było przekazać jako parametr.

Po co takie sztuczki ? :P Czy nie łatwiej jest powiedzieć CO (interfejs) 
ma robić i zaznaczyć, że WSZYSTKIE IMPLEMENTACJE MUSZĄ UWZGLĘDNIAĆ 
WIELOWĄTKOWOŚĆ? Pytanie brzmi - po co tak robić? Jeśli nie korzystasz z 
ogólnie przyjętych wzorców do synchronizacji wątków 
(producent-konsument, czytanie-pisanie, etc) to pakujesz się w problemy. 
I kolejne pytanie - po co informować klientów klasy, że muszą pamiętać o 
wielowątkowości? Nie lepiej ją schować za implementację (ukryć i 
wystawić interfejs)?

>
>> I teraz dochodzimy do zasadniczej kwestii. Jak wydzielić interfejs,
>> który przedstawia postawiony problem w sposób niezależny od wątków? Da
>> się? A jak się nie da, to pytanie brzmi dlaczego? Być może problem leży
>> w koncepcji...
>
> Nie zawsze można to zrobić, nie zawsze warto to robić, czasami dobrze
> jest zostawić wolną rękę implementacjom - w końcu kto powiedział, że
> jak implementujemy interfejs to nie możemy dodać coś od siebie i to
> udokumentować. Nie zawsze jest tak, że różne implementacje tego samego
> interfejsu są wzajemnie wymienne w naszym kodzie - i to dobrze. Weźmy
> taki przykład: interfejs Map - możemy mieć obiekt HashMap, ale możemy
> mieć też implementację zwracaną przez #Collections.synchronizedMap  -
> każdy z nich możemy przedstawić jako Map, ale działają inaczej, a
> interfejs Map nic na ten temat nie mówi. Z drugiej strony mamy
> interfejs np. BlockingQueue, który jasno wspomina jak to wszystko
> powinno działać biorąc pod uwagę wątki.

I tu się nie zgodzę. Map ma dobrze zdefiniowany interfejs. Wiadomo co on 
robi. I różne implementacje.

Dodawanie 'czegoś od siebie' (do głównego zbiornika) nie jest za dobre. 
Pewnie z powodu mieszania odpowiedzialności - to co chcesz dodać można 
by wydzielić jako osobny interfejs. Więc po co mieszać i wprowadzać 
konieczność rzutowania?

BlockingQueue jest implementacją interfejsu Queue. Interfejs Queue nie 
wie nic o tym, że MOŻE (albo ze JEST) implementacja będąca bezpiczena 
wątkowo. Dodatkowo, zobacz jaką sprytną implementacją. Bez zmiany metod 
interfejsu Queue dodaje współbieżność... Dokładnie tak jak ja tutaj 
próbuję wytłumaczyć, że wątki to dodatek, który zamiast eksponować 
powinno się ukrywać.

I dlatego moje pytanie - jak wydzielić CO od JAK. Jeśli się da - super. 
Jeśli się nie da - pomysł nie jest 'obiektowy' (w bardzo, bardzo 
rygorystycznym tego słowa znaczeniu)...

Pozdrawiam.
keef

keef pisze:
>> Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
>> miejscach, łącznie z tymi, które sam w swoim programie człowiek pisze
>> i od czasu gdy potrzebuje np. opakować metodę w obiekt, żeby można ją
>> było przekazać jako parametr.
> 
> Po co takie sztuczki ? 

znakomity przykład użycia masz właśnie w klasie Thread.

-- 
Pozdrawiam
Mateusz
http://na-jawie.blogspot.com

W dniu 2010-03-26 16:12, MZ pisze:
> keef pisze:
>>> Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
>>> miejscach, łącznie z tymi, które sam w swoim programie człowiek pisze
>>> i od czasu gdy potrzebuje np. opakować metodę w obiekt, żeby można ją
>>> było przekazać jako parametr.
>>
>> Po co takie sztuczki ?
>
> znakomity przykład użycia masz właśnie w klasie Thread.
>
Bomba! Czy jeszcze jakiś inny pomysł na użycie poza Thread? Czy chcesz 
może używając "sztuczki" napisać własny system wątków w javie? Czy 
widzisz jeszcze inne zastosowanie interfejsu Runnable, którego nie 
sposób rozwiązać przy użyciu polimorfizmu?

Rozumiem, że może to być szybsze, używać mniej pamięci, etc. Warto się 
zastanowić (znowu!) nad prawem Moora. Procki, kiedyś będą szybsze, 
pamięć tańsza i będzie jej więcej. A kod raz napisany brzydko, brzydkim 
zostanie (nawet jeśli został napisany przez 'unascribed' :P).

I nie, nie twierdzę, że java.lang.Thread jest 'złe' i brzydko napisane 
;-). Lecz cóż można powiedzieć, o klasie która ma ponad 1800 linii kodu 
(nawet jeśli część to javadoc. Jeśli wymaga to tyle pisania, aby 
zrozumieć działanie - na pewno może być prostsze :P) i 5 metod 'private 
native'... :P


I nie - nie napisałbym tego lepiej :P

Pozdrawiam
keef

On 26 Mar, 17:34, keef <a...@a.com> wrote:

> >>> Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
> >>> miejscach

> >> Po co takie sztuczki ?

> > znakomity przykład użycia masz właśnie w klasie Thread.

> Bomba! Czy jeszcze jakiś inny pomysł na użycie poza Thread?

Np. javax.swing.SwingUtilities.invokeLater(...)

Nie czepiaj się Runnable. To wyłącznie efekt konstrukcji języka, który
nie oferuje innych mechanizmów.
Runnable sam w sobie nie ma nic wspólnego z wątkami, więc jego użycie
w definicji klasy nie sugeruje wielowątkowości. To jest jedynie
znacznik: "uwaga, instancje tej klasy można wywołać", gdzie
"wywołanie" to właśnie run(). Kontekstów na użycie czegoś takiego jest
wiele.

Inne języki radzą sobie z tym problemem inaczej. Np. w C++ masz
przeciążalny operator wywołania funkcji - bardzo zgrabna konstrukcja,
bo składniowo unifikuje się z normalnymi funkcjami. I podobnie - można
to użyć do wątków, ale nie trzeba.
W Pythonie jest podobnie, ale w kontekście dynamicznym.
W Adzie można by było użyć generyków z dowolnym przemapowaniem
operacji w momencie jego konkretyzowania - czyli nie dość, że nie
trzeba używać interfejsu, to nawet nazwa operacji nie musi być
ustalona. Itd.
Ogólnie - istnienie Runnable wynika z konstrukcji Javy, więc on sam
niczemu nie jest winien.
Po prostu język taki jak Java musi mieć interfejs taki jak Runnable.

> Czy
> widzisz jeszcze inne zastosowanie interfejsu Runnable, którego nie
> sposób rozwiązać przy użyciu polimorfizmu?

Interfejs Runnable (jak i każdy inny) opiera się na użyciu
polimorfizmu, więc pytanie jest dziwne.

--
Maciej Sobczak * http://www.inspirel.com

W dniu 2010-03-26 22:47, Maciej Sobczak pisze:
> On 26 Mar, 17:34, keef<a...@a.com>  wrote:
>
>>>>> Runnable nie powstał tylko po to, stosuje się go w wielu wielu wielu
>>>>> miejscach
>
>>>> Po co takie sztuczki ?
>
>>> znakomity przykład użycia masz właśnie w klasie Thread.
>
>> Bomba! Czy jeszcze jakiś inny pomysł na użycie poza Thread?
>
> Np. javax.swing.SwingUtilities.invokeLater(...)
>
> Nie czepiaj się Runnable. To wyłącznie efekt konstrukcji języka, który
> nie oferuje innych mechanizmów.
> Runnable sam w sobie nie ma nic wspólnego z wątkami, więc jego użycie
> w definicji klasy nie sugeruje wielowątkowości. To jest jedynie
> znacznik: "uwaga, instancje tej klasy można wywołać", gdzie
> "wywołanie" to właśnie run(). Kontekstów na użycie czegoś takiego jest
> wiele.

Podobnie jak Serializable - również jest interfejsem znacznikowym.

Poza tym przeczytaj dokładnie o co chodzi - wyciąłeś ten tekst więc 
pozwól, że go wstawię:

<ciach>
(...)opakować metodę w obiekt, żeby można ją było przekazać jako parametr.
</ciach>

Nie czepiam się interfejsu Runnable. Pytam się, dlaczego ktoś używa tego 
samego rozwiązania we własnym kodzie? Ponieważ uważam, że jakkolwiek 
pasuje do wątków, to inne jego zastosowania są wątpliwe (w sensie - da 
się to zrobić lepiej - być może będzie wolniejsze/używać więcej pamięci 
- ale rozwiązanie będzie bardziej przejrzyste).

Czy nie lepiej jest użyć wzorca projektowego 'Komenda', który robi 
bardzo podobną rzecz, ale bez wiązania jej z wątkami? Równie dobrym 
wyjściem jest Callable<T>. Oba nie wymagają rzutowania, w 
przeciwieństwie od Runnable ;-)

>
> Inne języki radzą sobie z tym problemem inaczej. Np. w C++ masz
> przeciążalny operator wywołania funkcji - bardzo zgrabna konstrukcja,
> bo składniowo unifikuje się z normalnymi funkcjami. I podobnie - można
> to użyć do wątków, ale nie trzeba.
> W Pythonie jest podobnie, ale w kontekście dynamicznym.
> W Adzie można by było użyć generyków z dowolnym przemapowaniem
> operacji w momencie jego konkretyzowania - czyli nie dość, że nie
> trzeba używać interfejsu, to nawet nazwa operacji nie musi być
> ustalona. Itd.
> Ogólnie - istnienie Runnable wynika z konstrukcji Javy, więc on sam
> niczemu nie jest winien.
> Po prostu język taki jak Java musi mieć interfejs taki jak Runnable.
>
Zgadza się. I teraz dyskutujemy jak go używać :-)

Pomimo tego, że możliwe jest, jak ktoś zaproponował, dziedziczenie po 
Thread, lub pisanie explicite "public interface MyFancyBussinesLogic 
extends Runnable", pytanie brzmi "po co tak robić?". Czy rzeczywiście 
klienci interfejsu MyFancyBussinesLogic muszą wiedzieć o wątkowości? A 
nawet jeśli, to dlaczego rozszerzać interfejs? Czy nie lepiej ukryć 
wątków wewnątrz implementacji?

Jeśli weźmiesz mój przykład z "private static class ThreadedAaa". 
Pominąłem tam oczywiście metody, które powodują, iż obiekty działają w 
osobnym wątku - skupiłem się na pokazaniu, iż "MyFancyBussinesLogic" nie 
musi "extends Runnable" i również można używać wątków :-)

>> Czy
>> widzisz jeszcze inne zastosowanie interfejsu Runnable, którego nie
>> sposób rozwiązać przy użyciu polimorfizmu?
>
> Interfejs Runnable (jak i każdy inny) opiera się na użyciu
> polimorfizmu, więc pytanie jest dziwne.
>

Nie. Sam napisałeś - znacznik. Więc Runnable, Serializable opierają się 
na polimorfizmie bardzo słabo...

Dość powiedzieć - dziedziczenie klasy, która jest 'Serializable' jest 
trudne. Musisz pamiętać, aby wszystkie klasy były odpowiednie - nie 
zawierały (agregowały) obiektów, które nie są Serializable.

Podobnie 'Runnable' - łącząc interfejs Runnable z Twoją logiką 
(interface MyFancyBussinesLogic extends Runnable) łączysz wątkowość _na 
zawsze_ z Twoją logiką - z każdą implementacją. I z każdą klasą potomną 
musisz pamiętać, że kod działa w wątku. Warto? Z drugiej strony możesz 
zdefiniować interfejs (MyFancyBussinesLogic) i dostarczyć jego 
implementację, która działa w wielu wątkach 
(ThreadedMyFancyBussinesLogic) i nie narzuca klasom dziedziczącym 
konieczności pamiętania o bezpieczeństwie wątkowym, zwalnianiu puli 
wątków, etc.

A dlaczego uważasz, że implementacja jednowątkowa jest zła tak bardzo, 
że z gruntu wykluczasz, iż będzie działać (extends Thread zmusza Cię do 
zapewnienia możliwości uruchomienia w osobnym wątku)? :P

Mam nadzieję, że przedstawiłem swój punkt widzenia :-)

Pozdrawiam.
keef

On 27 Mar, 00:10, keef <a...@a.com> wrote:

> > Runnable sam w sobie nie ma nic wspólnego z wątkami, więc jego użycie
> > w definicji klasy nie sugeruje wielowątkowości. To jest jedynie
> > znacznik: "uwaga, instancje tej klasy można wywołać",

> Podobnie jak Serializable - również jest interfejsem znacznikowym.

Nie, to co innego.
Pisząc "znacznik" miałem na myśli, że ten interfejs wyraża pewną
"zdolność" (zresztą jak każdy inny interfejs, więc może bez sensu to
napisałem).
Natomiast Serializable jest znacznikiem rozpoznawanym przez kompilator
i to działa na innym poziomie. Prawdopodobnie gdyby anotacje były w
Javie od początku, to interfejsu Serializable by po prostu nie było,
bo to jest bardzo kiepski sposób na znacznikowanie czegokolwiek.

> Poza tym przeczytaj dokładnie o co chodzi - wyciąłeś ten tekst więc
> pozwól, że go wstawię:
>
> <ciach>
> (...)opakować metodę w obiekt, żeby można ją było przekazać jako parametr.
> </ciach>
>
> Nie czepiam się interfejsu Runnable. Pytam się, dlaczego ktoś używa tego
> samego rozwiązania we własnym kodzie?

Bo ma podobny use-case.

> Ponieważ uważam, że jakkolwiek
> pasuje do wątków, to inne jego zastosowania są wątpliwe

Pokazałem przykład z GUI.

> Czy nie lepiej jest użyć wzorca projektowego 'Komenda', który robi
> bardzo podobną rzecz, ale bez wiązania jej z wątkami?

Runnable niczego nie wiąże z wątkami, już pisałem.

> Równie dobrym
> wyjściem jest Callable<T>.

Jeśli chcesz coś zwracać.

> Oba nie wymagają rzutowania, w
> przeciwieństwie od Runnable ;-)

Jakiego rzutowania wymaga Runnable?
Zwłaszcza, że run() niczego nie zwraca?

> Pomimo tego, że możliwe jest, jak ktoś zaproponował, dziedziczenie po
> Thread, lub pisanie explicite "public interface MyFancyBussinesLogic
> extends Runnable", pytanie brzmi "po co tak robić?".

Dziedziczenie po Thread to faktycznie robienie wiochy, ale
MyFancyBusinessLogic może w ten sposób wyrazić swoją gotowość do bycia
wywołanym.

> Czy rzeczywiście
> klienci interfejsu MyFancyBussinesLogic muszą wiedzieć o wątkowości?

Nie ma tu mowy o wątkach.
(dlatego wycinam dalsze Twoje uwagi o wątkach)

> > Interfejs Runnable (jak i każdy inny) opiera się na użyciu
> > polimorfizmu, więc pytanie jest dziwne.
>
> Nie. Sam napisałeś - znacznik. Więc Runnable, Serializable opierają się
> na polimorfizmie bardzo słabo...

Runnable to prawdziwy interfejs z prawdziwą metodą, która jest
naprawdę definiowana przez klasę implementującą ten interfejs.
Polimorfizm pierwsza klasa.

> Podobnie 'Runnable' - łącząc interfejs Runnable z Twoją logiką
> (interface MyFancyBussinesLogic extends Runnable) łączysz wątkowość

Znowu nie. Runnable nie implikuje żadnej wielowątkowości.

> A dlaczego uważasz, że implementacja jednowątkowa jest zła tak bardzo,

Może być bardzo dobra. Dlatego bardzo dobrym przykładem jest
invokeLater ze Swinga - ona jest *właśnie* po to, żeby dopasować się
do jednowątkowej implementacji jakiegoś kawałka systemu.

> Mam nadzieję, że przedstawiłem swój punkt widzenia :-)

Jak najbardziej.

--
Maciej Sobczak * http://www.inspirel.com

Mialem sie powstrzymac, ale tym razem nie wytrzymam.

>
> Coz moge odpowiedziec... moze to:http://catb.org/~esr/faqs/smart-questions.html#not_losing
>

Cóż takiego zmieniło się w stosunkach międzyludzkich wraz z
wprowadzeniem Internetu, że starą dobrą kulturę osobistą powinniśmy
zastępować netykietą ?

Zenon

Poczytałem sobie trochę tę dyskusję oraz przykłady Pana Salwickiego i
mam wrażenie, że chodziło o coś innego niż Panowie piszecie.

Proszę mnie poprawić, jeżeli się mylę ale chyba Pan Salwicki chciał
potraktować aktywne obiekty jako coś w rodzaju niezależnych procesów.
Jeśli to ma działać jednakowo w środowisku współbieżnym i równoległym,
to nie możemy zakładać dostępu do systemu wątków realizowanego w JVM
(bo to niekoniecznie jedna JVM) ani też np. synchronizowanych kolejek.
Chodzi chyba o to aby obiekty dogadywały się samodzielnie.

Niestety daleko mi do poziomu prezentowanego przez obecnych tu
specjalistów nie podam zatem żadnego rozwiązania, nie jestem nawet
pewien czy udało mi się poprawnie zdefiniować problem. Chciałem
jedynie zwrócić Państwa uwagę, że być może problem jest bardziej
badawczy niż inżynierski i niepotrzebnie na wyścigi rozpoczęliście
Panowie dysputę nad jego sensownością (przynajmniej niektórzy z
dyskutantów).

Bez względu na to ile pogardy włożą w swoje wypowiedzi o
uniwersytetach panowie Michał Kleczek, Tadeusz B. Kopeć czy Maciej
Sobczak - uniwersytety właśnie tym się zajmują - badaniem różnych
dziwnych, być może niepotrzebnych rzeczy. Te potrzebne, dobre,
sprawdzone, używane przez Was zostały już zbadane...

Pozdrawiam,
Zenon Zalewski

Zenon Zalewski wrote:

> Poczytałem sobie trochę tę dyskusję oraz przykłady Pana Salwickiego i
> mam wrażenie, że chodziło o coś innego niż Panowie piszecie.
> 
> Proszę mnie poprawić, jeżeli się mylę ale chyba Pan Salwicki chciał
> potraktować aktywne obiekty jako coś w rodzaju niezależnych procesów.
> Jeśli to ma działać jednakowo w środowisku współbieżnym i równoległym,
> to nie możemy zakładać dostępu do systemu wątków realizowanego w JVM
> (bo to niekoniecznie jedna JVM) ani też np. synchronizowanych kolejek.
> Chodzi chyba o to aby obiekty dogadywały się samodzielnie.

W Javie to sa sprawy niezalezne od siebie, tzn:
1. wielozadaniowosc w ramach jednej JVM
2. komunikacja ze zdalnymi obiektami (a raczej zdalne wywolywanie metod)

1 jest realizowane przy pomocy watkow z mechanizmami synchronizacji 
zaimplementowanymi w jezyku (slowo kluczowe synchronized) i bibliotece 
standardowej (metody wait()/notify()/notifyAll() klasy Object, klasa Thread 
i inne)

2 jest (a wlasciwie moze byc, bo sa inne sposoby) realizowane przez (jakzesz 
by inaczej) RMI


> 
> Niestety daleko mi do poziomu prezentowanego przez obecnych tu
> specjalistów nie podam zatem żadnego rozwiązania, nie jestem nawet
> pewien czy udało mi się poprawnie zdefiniować problem. Chciałem
> jedynie zwrócić Państwa uwagę, że być może problem jest bardziej
> badawczy niż inżynierski i niepotrzebnie na wyścigi rozpoczęliście
> Panowie dysputę nad jego sensownością (przynajmniej niektórzy z
> dyskutantów).
> 
> Bez względu na to ile pogardy włożą w swoje wypowiedzi o
> uniwersytetach panowie Michał Kleczek, Tadeusz B. Kopeć czy Maciej
> Sobczak - uniwersytety właśnie tym się zajmują - badaniem różnych
> dziwnych, być może niepotrzebnych rzeczy. Te potrzebne, dobre,
> sprawdzone, używane przez Was zostały już zbadane...

Wywolany z nazwiska odpowiem.
Nie napisalem ani jednego slowa pogardy w stosunku do uniwersytetow. 
Zareagowalem tylko (fakt - ostro) na odpowiedzi OP wobec porad grupowiczow 
brzmiaca jak przepisany komentarz nauczyciela do zle odrobionej pracy 
domowej lub wrecz niegrzeczne, cytuje: "Obawiam się, że pytanie jest zbyt 
trudne" "Te rozwiazania nie satysfakcjonuja".
W polaczeniu z ewidentnym brakiem zrozumienia OP podstawowych pojec Javy (co 
swiadczy o tym, ze OP nie poswiecil _odrobiny_ czasu na zapoznanie sie z 
tematem) takie komentarze IMHO zaslugiwaly na odpowiedz - niezaleznie od 
tego, kto jen napisal.

Problem mozna postawic w sposob taki, jak zrobil to OP lub np zgodnie z 
zasadami opisanymi tu:
http://catb.org/~esr/faqs/smart-questions.html
po polsku tu:
http://rtfm.killfile.pl/

Szczegolnie:
http://rtfm.killfile.pl/#cel

Opis problemu (czyli porownanie, czy tez implementacja cech Loglana w Javie) 
nastapil _po_ moim poscie. Nie mozna bylo od razu?

-- 
Michal

> W Javie to sa sprawy niezalezne od siebie, tzn:
> 1. wielozadaniowosc w ramach jednej JVM
> 2. komunikacja ze zdalnymi obiektami (a raczej zdalne wywolywanie metod)
>
> 1 jest realizowane przy pomocy watkow z mechanizmami synchronizacji
> zaimplementowanymi w jezyku (slowo kluczowe synchronized) i bibliotece
> standardowej (metody wait()/notify()/notifyAll() klasy Object, klasa Thread
> i inne)
>
> 2 jest (a wlasciwie moze byc, bo sa inne sposoby) realizowane przez (jakzesz
> by inaczej) RMI
>

Być może o taką odpowiedź właśnie chodziło, nie wiem, bo autor wątku
od dłuższego czasu się nie odezwał...

> Wywolany z nazwiska odpowiem.
> Nie napisalem ani jednego slowa pogardy w stosunku do uniwersytetow.

Proszę nie traktować tego tak dosłownie.


> Zareagowalem tylko (fakt - ostro) na odpowiedzi OP wobec porad grupowiczow
> brzmiaca jak przepisany komentarz nauczyciela do zle odrobionej pracy
> domowej lub wrecz niegrzeczne, cytuje: "Obawiam się, że pytanie jest zbyt
> trudne" "Te rozwiazania nie satysfakcjonuja".
> W polaczeniu z ewidentnym brakiem zrozumienia OP podstawowych pojec Javy (co
> swiadczy o tym, ze OP nie poswiecil _odrobiny_ czasu na zapoznanie sie z
> tematem) takie komentarze IMHO zaslugiwaly na odpowiedz - niezaleznie od
> tego, kto jen napisal.

Och, osobiście nie odebrałem komentarzy nauczyciela jako obraźliwych
ale rozumiem, że można było i tak. Wniosek jest jeden - wszystkim nam
przyda się odrobina dystansu i spokoju.
Słowo pisane nie oddaje najwyrażniej wszystkich intencji piszącego i
trzeba podchodzić do niego z rezerwą, zwłaszcza jeśli w grę wchodzą
emocje...


> Problem mozna postawic w sposob taki, jak zrobil to OP lub np zgodnie z
> zasadami opisanymi tu:http://catb.org/~esr/faqs/smart-questions.html
> po polsku tu:http://rtfm.killfile.pl/
>
> Szczegolnie:http://rtfm.killfile.pl/#cel

Problem można przedstawić na różne sposoby. Doceniam trud włożony w
przygotowanie dokumentów, które Pan wskazuje ale nie przeceniałbym ich
roli (błagam, proszę nie traktować tego jako personalnego przytyku, to
tylko moja opinia... ) . Nasz gatunek potrafił dyskutować na długo
przed pojawieniem się komputerów, mam zatem nadzieję, że jako
inteligentni ludzie sami jesteśmy w stanie wypracować metody
komunikacji.

Żeby nie zrobił się z tego kompletny offtop, czytałem gdzieś kiedyś
(nie pamiętam dokładnie gdzie) o koncepcji Active Objects w Javie
(czyli wykonywaniu metody w kontekście jej właściciela a nie
wywołującego - chyba ktoś o tym wspominał tutaj). Myślę, że to mogłoby
trochę pasować do postawionego problemu. Propozycja realizacji
opierała się na "dynamic proxies".


Pozdrawiam,
Zenon Zalewski

pavS8d  <a href="http://spymbtdfcjox.com/">spymbtdfcjox</a>, 
[url=http://iybmjcjvpaqy.com/]iybmjcjvpaqy[/url], 
[link=http://aotbkjbbdxdt.com/]aotbkjbbdxdt[/link], 
http://xaxbuxcodabq.com/