🚀 go-pugleaf

A.L. wrote:

> Ja osobiscie uzywam Gigaspaces 
> 
> http://gigaspaces.com/pr_overview.html

Tego nie znałem, przyjrzę się...

> z dobrym skutkiem oraz w innej aplikacji JCSP
> 
> http://www.cs.kent.ac.uk/projects/ofa/jcsp/

Ta biblioteka (od kiedy ją Pan po raz pierwszy polecał), to wciąż jakoś 
mnie nie przekonuje.  Przetestować jej za bardzo nie miałem gdzie, 
wierzę, że się sprawdza, jednak patrząc w bebechy zdziwiłem się mocno 
widząc w użyciu tylko stare mechanizmy synchronizacji Javy -- oparte na 
monitorach.  Wygląda to tak, jakby o atomowej synchronizacji autorzy nie 
słyszeli?!


Teksty w stylu:

Fair servicing of writers to this channel depends on the fair servicing 
of requests to enter a synchronized block (or method) by the underlying 
Java Virtual Machine (JVM). Java does not specify how threads waiting to 
synchronize should be handled. Currently, Sun's standard JDKs queue 
these requests - which is fair. However, there is at least one JVM that 
puts such competing requests on a stack - which is legal but unfair  and 
can lead to infinite starvation. This is a problem for any Java system 
relying on good behaviour from synchronized, not just for these any-1 
channels.

są już dziś nieco śmieszne, zważywszy obecność, od dwóch lat, wbudowanej 
w Javę biblioteki Douga Lea, która zresztą wcześniej także już była 
dostępna...

A może autorzy uznali, że to tylko nieistotny szczegół implementacyjny? 
  I stosowanie JCSP w obrębie jednej JVMy nie ma większego sensu?

Jest tam też przecież cały ten moduł sieciowy (nie przyglądałem się 
zbytnio), który, jak Pan też niedawno informował, sporo kosztował, a 
teraz można go używać za free.  Więc może i drobiazgi takie jak powyżej 
nie są już istotne wtedy?  Nie wiem...


Szczerze mówiąc, to nie całkiem widzę, co tak naprawdę cennego daje JSCP 
w porównaniu z tym co dziś w java.util.concurrency.** jest?  (Skupiając 
się na równoległości w obrębie jednej maszyny oczywiście.)


> Wedle mocih najlepszych informacji nei widac zadnej rewolucji. Od czsu
> do czasu pojawiaja sie rozne produkty komercyjne do "programowania
> roznoleglego nie pzrerywajac snu", ale po dokladniejszym poskrobanoiu
> okazuja sie jakims tam opakowaniem Java threads.
> 
> "Nie przerywajac snu" okaze sie chyba niemozliwe, albowiem glowna
> trudnosc przy programowaniu rownoleglym to "zrownoleglenie" algorytmu
> tak aby z rownoleglosci byl jakis zysk. Bardzo latwo "zrownoleglic"
> algorytm tak ze na 50 komputerach bedzie dzialal wolniej nie na
> jednym.

To oznaczyłoby raczej, że problem jest w komunikowaniu się procesów, a 
nie samym "zrównoleglaniu".  Samo współdzielenie danych na tych 
wszystkich maszynach może być kolosalnym problemem, jak sądzę, choć może 
jednak w świecie superkomputerów uznaje się to za nieistotny szczegół?...

Z mich skromnych doświadczeń, opartych głównie na zrównoleglaniu wątków, 
to największe straty tkwią w przestojach wątków, a dokładniej w 
momentach przejścia w stan działania, po oczekiwaniu na sygnał "już" od 
pozostałych.  W skrócie, narzuty synchronizacji.

Zapewne znacznie trudniejsze zadanie, to znalezienie miejsc, w których 
"praca" może być wykonywana równolegle, czyli po części zbudowanie 
algorytmu na nowo, niemiej nawet jeśli się uda, nie gwarantuje to 
jeszcze żadnego zysku, i jak rozumiem, to właśnie ma Pan na myśli mówiąc 
o "nie przerywaniu snu", czy tak?


Pytanie, czy JCSP może jakoś w tym pomóc?  Coś więcej mógłby Pan na 
temat tej biblioteki powiedzieć?  Zachęcić bardziej do bliższego 
poznania wskazując dobre i złe strony?


> Ciemno to widze, przynajmniej w USA biorac pod uwage poziom
> wyksztalcenia matematyczno/algorytmicznego na przecietnym amerykanskim
> uniwersytecie

Czyżby nadzieja już tylko w Chińczykach?... ;)


piotr