Vlákno názorů k článku Síťování v Javě: Úvod od M.L. - Zajimavy pristup, pouzit vice vlaken. Proc to delat...
-
Zajimavy pristup, pouzit vice vlaken. Proc to delat jednoduse, ze ;-))
Copak se v Jave neda pouzit neco na zpusob syscallu select(2)? Tzn. funkce/trida ktere predam pole streamu ze kterych chci cist (stdin, net) a ona bude cekat az do doby nez jeden z tech streamu ma k dispozici data. Pak mi rekne ktery to byl a ja muzu vesele pokracovat. To je, rekl bych, mnohem jednodussi a standardnejsi pristup nez machrovani s threadama... -
Jednak je rozdil mit thready dva nebo jich mit dva tisice, kdyz mate tisic spojeni.Tak to je určitě rozdíl.
A potom, nejde ani tak o rychlost, jako o jednoduchost kodu (s thready musite davat bacha, co musi byt synchronized atp.)To bych ani neřekl. Přece jen se každý thread stará o své vlastní spojení a s ostatními "spojovacími" vlákny nemá důvod komunikovat. Jediné, co je nutné synchornizovat (ale to vždycky), jsou objekty společné všem vláknům. Psal jsem (přiznávám, jednoduchý) komunikační program pro LAN (v C#) a pro každého uživatele, kterého jste měl v seznamu, běžel jeden thread, který zjisťoval jeho stav (tj. to vlákno bylo skoro pořád ve stavu sleep) + další vlákna pro otevřená okna, kde jste si chatoval s tím daným uživatelem. Rozdělení do threadů bylo velmi jednoduché a přineslo daleko větší možnosti. Max počet vláken toho programu co jsem zkoušel byl 60, což není vůbec moc.
-
Dovolil bych si podotknout, ze pokud v Jave pouzivate GUI - a urcite i v jinych pripadech (zalezi na implementaci dotycne oblasti) - tak Vase aplikace JE vicevlaknova, aniz byste se toho jako aplikacni programator ucastnil... Takze hrani si na pidimetry vykonu pres Select/Poll aniz bych znal technologii mi prijde usmevne...:-)
-
Ale ono je to tak správně. Tento přístup (neblokující) se v praxi samozřejmě využívá s několika vlákny, nejen s jedním. Jejich počet je ale výrazně nižší (např. roven násobku počtu procesorů - 4, 8 a podobně). Dost dobře nechápu Tvůj komentář. Jinak ale přístup s více vlákny zde bude pořád - někde se třeba hodí lépe.
-
Dost dobře nechápu Tvůj komentář.
Pouze mě zaráží, že se "tolik" píše proti použití vlákna na každé spojení. Nic víc nic míň.
I procesory x86 udělali hodně velký pokrok, co se týče zpracování mnoha procesů (např. rychlejší přepínání kontextu, masivní paralelismus uvnitř CPU -- na GPU to ještě nemá, ale snad časem, "inteligetní" prefetch do cache). A bude se to zlepšovat. Budou přibývat jádra, zvětšovat se cache, měnit se celá architektura PC (AMD například používá NUMA ve svých multiprocesorových řešeních, místo "klasického" SMP na FSB jak má Intel). Tak nevidím důvod, proč nemít v programu třeba 512 vláken. Možná se mýlím a rád se nechám poučit.
-
Palo (neregistrovaný)Treba rozlisovat medzi Threadmi na klientovi a v servri. Na servri treba setrit pretoze uz iba kontext switching medzi 1000 threadmi ti zozerie dost velku cast CPU.
Na servri je pouzitie select() nevyhnutnostou. Specialne co sa tyka triedy java.net.Socket ma problem ze za urcitych okolnosti nie je mozne rozlisit ze socket bol z druhej strany zatvoreny (programovo alebo z dovodu sietovej chyby) takze takto napisany server po case lahne.
Nadmerna zataz (sietova,...) zlozi akykolvek server. V dobrom servri ktory ma byt odolny aj proti DoS utoku musis mat dobre vyriesene fronty, cakacie stavy a aj odmietanie poziadaviek. -
Blera (neregistrovaný)V baliku NIO samozrejme select() je a i ostatni veci tady funguji na podobnem principu, jako v "C-cku".
S temi vlakny je spis problem ten, ze pokud bude tech komunikaci vice, pak nam vlakna budou narustat a narustat.
Druha vec je ta, ze uvedeny kod se netyka Telnet klienta, ale TCP trubky. Telnet zpracovava signaly typu Ctrl-C, Ctrl-Z a podobne veci, ktere by zarizeni typu TTY melo umet. -
Jarda (neregistrovaný)Takze misto 'machrovani s Threadama' (= dvakrat pouziti stejne jednoduchoucke tridy) nasadime nejake podminky/pomocne struktury na rozhodovani kam se ma zapisovat, zacneme resit problemy se zablokovanim vystupu a tim padem zablokovanim obsluzneho vlakna atd? Tomu se ted rika jednoduchost?:)
Vzhledem k tomu, ze melo jit o jednoduchou ukazku prace se siti, tak je to imho v pohode, az budete mit server obsluhujici tisic spojeni najednou, tak jsou selecty na miste. A co se standardnosti tyce, tezko rict, ale co jsem videl, tak mi prijde, ze se tenhle pristup opravdu hodne pouziva, prace s vlakny je v Jave jednoducha a dokud jich staci par...
ČLÁNKY DO MAILU