Vicevlaknove programovani v Jave

8.5.2008 21:33 | Přečteno: 2277×

Zaujal me dotaz na vicevlaknove aplikace v C++. Zkusim trochu provokovat a dam par odkazu na multithread v Jave. Skvele pro zacatecnika, dobre pro inspiraci. Java ma oproti C++ vyhodu je ze je od zacatku navrzena jako vicevlaknova. Vedet zda objekt je inmutable a thread safe je k nezaplanaceni.

Vynecham jak snadne je spustit thread, pouziti slova synchronized a rovnou skocim na "lahudky". Swing

Problem swingu (GUI toolkitu v Jave) je ze je jednovlaknovy. K prostredkum se muze pristupovat pouze z jednoho thread (AWT event dispath thread). Pokud se v tomhle vlakne dela delsi operace, GUI se nemuze prekreslovat a "zamrzne", je to spolecny problem i C++ aplikaci.

Skvela je knihovna Foxtrot ktera umoznuje "odskocit" si do sousedniho threadu. Pritom pocka nez se uloha dokonci a neblokuje GUI thread. GUI se tedy normalne prekresluje. Skvele je jak snadne je tohle "odskoceni".

Priklad:

{
  //nacti URL v GUI thread
  URL url = new URL(text.getText());
  //stahni data bez blokace GUI
  String data = (String) Worker.post(new Job(){
   public Object run(){
     return URL.stahniData()
   }
  }
  //a zobraz data
  page.setData(data)
}

Podobne funguje napriklad SwingWorker

A totalne "cool" je Spin ktery obali objekt proxy, ktera se stara o thrading sama.

Concurrent utils

Od jre 1.5 je mozne pouzivat knihovnu obsahujici locky, queue, semafory, executory... Vice v java docu

Literatura

Velmi dobre jsou dve knizky. Obe jdou stahnout z netu...: Tahle probira zaklady multithreadingu a utility v jave, dobre pro zacatecniky,

Java Concurrency in Practice 
By Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea 
Publisher: Addison Wesley Professional 
Pub Date: May 09, 2006 
Print ISBN-10: 0-321-34960-1 
Print ISBN-13: 978-0-321-34960-6 
Pages: 384 

A tato dava teoreticko/prakticke znalosti. V Java komunite je to best seller

Concurrency: State Models & Java Programs, 2nd Edition 
byJeff MageeandJeff Kramer 
John Wiley & Sons 2006 (432 pages) 
ISBN:0470093552 

       

Komentáře

[alblaho]

To je nějaká magie, ne? Ten příklad na mě dělá dojem, že AWT-event vlákno stejně zamrzne - čeká dokud pracovní vlákno nedodá ty data.

[Trained.Monkey]

Foxtrot na pozadi dal dispatchuje eventy v cyklu. Az work thread dobehne, tak se cyklus prerusi a pokracuje se dal v AWT threadu.

[alblaho]

To mě nenapadlo. Chytrý hack

[Filip Jirsák]

Tenhle princip, že musí kterékoli vlákno občas zpracovat události, se používá třeba ve WinAPI. Ale nejsem si jist, jestli to bude za každých okolností dobře fungovat ve Swingu – tam totiž všichni předpokládají, že události bude zprácovávat právě to určené vlákno. Takže pokud se nějaká událost zpracovává v jiném vlákně, a zároveň někdo spustí něco ve vlákně AWT, může se stát, že obě vlákna budou manipulovat se stejným objektem a něco si přepíšou.

[alblaho]

Ale to právě řeší ten Foxtrot, ne? Foxtrot spustí nové vlákno, které bude obsluhovat události po dobu, kdy je "nativní" event-loop vlákno zablokované, protože čeká na dokončení nějaké dlouhé operace.

[Filip Jirsák]

Pak ale toto nové vlákno spustí nějaký ovladač události, který bude předpokládat, že je ve vlákně AWT – a začne třeba něco překreslovat. Jenže mezitím se zablokované skutečné AWT vlákno odblokuje (skončila operace, která ho blokovala) a také začne překreslovat, nejlépe ten samý objekt. A to nemusí dopadnout dobře…

[Ladicek]

To se dá bez problémů řešit jedním zámkem (a formálním důkazem, že nedojde k deadlocku ). Tedy ne že bych nesouhlasil, že je to prasárna. Osobně si myslím, že tenhle problém může krásně řešit návrh lexikálních uzávěrů pro Javu 7 od Neala Gaftera a spol.

[Filip Jirsák]

To se dá bez problémů řešit jedním zámkem

Teoreticky jistě, ostatně jak už jsem psal, jiné GUI systémy nepoužívají systém vlákna určeného ke zpracování událostí, ale události zpracovává kterékoli vlákno. Ale v AWT/Swingu je k tomu určené vlákno (vlákna), a zavést do toho nějaký zámek by znamenalo, že musí všichni začít ten zámek používat. Což můžu udělat třeba ve svém kódu, ale těžko budu takovému zámku přizpůsobovat knihovny třetích stran nebo dokonce runtime knihovnu.

Dokumentace k AWT vláknům začíná větou: „Unless otherwise noted all AWT listeners are notified on the event dispatch thread.“ Takže cokoliv, co tenhle předpoklad naruší, má dobře našlápnuto k tomu, aby to někde něco rozbilo.

[Jirka P]

Ne, je to naopak. Foxtrot pustí nové vlákno, které provádí tu dlouhou operaci, a mezitím v nativním vlákně spustí vnořenou smyčku událostí. Ne, že by to bylo úplně bezpečné, ale jde to.

[Filip Jirsák]

Aha, to je pak ale přesně opačně, než tady napsal někdo na začátku vlákna. Pak je to ale klasický SwingWorker, který je na internetu v desítkách variant a který je už součástí Javy 6.

[HNT]

A tim "jdou stahnout z netu" bylo mysleno ukrast na torrentu, nebo jsou nekde volne a legalne ke stazeni? Budu vdecny za odkazy, diky.

[Luboš Doležel (Doli)]

Java ma oproti C++ vyhodu je ze je od zacatku navrzena jako vicevlaknova. Vedet zda objekt je immutable a thread safe je k nezaplanaceni.

Když dám v C++ const, tak je objekt taky immutable.

[Kyosuke]

A nějaké ty knihovny pro usnadnění práce s vlákny by se určitě taky našly.

[Luk]

Problem swingu (GUI toolkitu v Jave) je ze je jednovlaknovy. K prostredkum se muze pristupovat pouze z jednoho thread (AWT event dispath thread).

To není problém, to je vlastnost. Má totiž tu zásadní výhodu, že se nemusí používat synchronizace a nevzniká tedy ani s ní spojená režie, která by byla mnohdy úplně zbytečná.

Kdo chce pracovat se Swingem ve více vláknech, může buď použít nějakou nadstavbu nebo si to udělat přímo podle potřeby (tj. sahat do GUI přes invokeLater(), invokeAndWait() a podobně).

[Filip Jirsák]

Problem swingu (GUI toolkitu v Jave) je ze je jednovlaknovy. K prostredkum se muze pristupovat pouze z jednoho thread (AWT event dispath thread).

Tohle není tak docela pravda. Se Swingem (resp. AWT) by se mělo manipulovat pouze z vlákna AWT, to ano, ale to vlákno nemusí být jen jedno, může jich být víc.

[Andrei Badea]

to vlákno nemusí být jen jedno, může jich být víc.

Aktivnich v jednom okamziku? Poslal bys prosim nejaky odkaz? Nechci polemizovat, jen se divim. Dost metod jak ve Swingu tak v AWT zamyka AWT tree lock. Pristup z vice vlaken si primo rika o deadlock s nejakym uzivatelovym zamkem. Nebo mas na mysli nahrazeni EventQueue jinou pres metody push() a pop()?

[Filip Jirsák]

Bral jsem to podle toho, že už jsem v debuggeru těch vláken AWT-EventQueue viděl víc. Ale podle zdrojáku je to tak, jak píšete – v zásobníku může být sice vláken víc, ale aktivní je jen to na vrcholu. A třeba právě metoda isDispatchThread() vrací true právě jen v případě, že se jedná o to aktivní vlákno na vrchu zásobníku. Ale stejně to znamená, že by člověk měl vždy pracovat s metodami z EventQueue a ne se pokoušet jednou na začátku si EventQueue vlákno zapamatovat a pak už pracovat vždy s ním. A taky to znamená, že je nesmysl pokoušet se zpracovávat události ve vlastním vlákně, abych mohl zablokovat vlákno událostí. EventQueue už má tenhle mechanizmus zabudován v sobě a pokud už bych opravdu chtěl déletrvající zpracování události provádět ve vlákně událostí, je rozumnější před vlastním zpracováním vytvořit nové vlákno fronty zpráv, dát ho na vrchol zásobníku, pak si v původním vlákně můžu dělat co chci a když skončím, nově vytvořené vlákno zase odstraním.

[Andrei Badea]

Dekuju za upresneni, takhle tomu rozumim i ja: aktivni muze byt jen jedna EventQueue.