Vicevlaknove programovani v Jave (diskuse)

[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.