> Mezi nejdulezitejsi a nejkritictejsi cast tohoto SW patri komunikacni modul, > ktery obsluhuje pripojena zarizeni. Problemem je, jak zajistit aby vlakno > (tento komunikacni modul) bylo temer vzdy uprednostnovano pred vlakny, ktere > obstarava ostatni narocnou praci (napr. praci s DB). > (Program by mel fungovat jak na Linuxu, tak na Windows - jenze priorita vlaken > mi jde nastavit jen na windowsech - na Linuxu nema nastaveni priority vlaknu > zadny efekt ... presto se mi zda, ze se Linux chova pri planovani procesu lepe > nez Windowsy.)
^-- Akykolvek program, ktory ku spravnej cinnosti potrebuje manipulaciu s prioritami, je nestastny, mnohi by nevahali nazvat ho chybnym (a mozno by som aj ja s nimi suhlasil). Kazdopadne mam za to, ze prioritu vlakien v Jave mozno tak isto nastavovat vo Windowse aj v Linuxe. Otazka je, ako su v tej-ktorej platformovej a vendorovej implementacii Javy vlakna implementovane, a teda ci to prostriedkami operacneho systemu bude viditelne a ako. Mozu to byt skutocne len programove thready, vtedy jadro vidi jeden proces, o "priority" sa stara JVM. Toto je vsak uz v dnesnej dobe nepravdepodobne. Potom moze byt kazdy thread samostatnym procesom a nastavenie "priority" z Javy sa moze preniest az na prioritu prislusneho OS procesu; takto by to mohlo byt vo Win. Napr. na Solarise by taky program skoncil ako LWPs (LightWeight Processes), co je nejaky dost zlozity hybrid medzi ciste procesmi a ciste threadmi (navyse to ani nie su celkom striktne LWPs, ale to uz nebudeme Sun-u brat, ze ano :-)). Na a teda je jasne, ze k odozve vela povie samotny OS a jeho scheduler. Ako ste sam uviedli, rozdielny OS produkuje rozdielne spravanie. > Soucasny SW tento problem resil tak, ze oddelil tyto dve casti do zvlastnich > programu, ktere spolu komunikovali pres sdilenou pamet - pry se to chovalo > mnohem lepe, a komunikace pak nevazla. ^-- To je riesenie, ktore mi napdalo ako prve, este skor, ako som si precital tento odstavec. Urobit dva programy: jeden bude spusteny s vysokou prioritou, bude obsluhovat pripojene zariadenia a bude druhemu modulu "posielat spravy" (technologicke riesenie necham na Vas). Druhy modul bude v klude tieto spravy spracovavat, ked na to bude cas, pricom bude pouzivat vsemozne blokujuce volania (FS, DB, network). > Ja bych radeji napsal tento novy program jako celek - nebo myslite, ze by bylo > lepsi tyto casti oddelit? -- a v tom pripade jak nejlepe/nejrychleji zajistit ^-- Navrhujem oddelit. > komunikaci mezi temito castmi MemoryMappedFile / RMI / RPC ?? ^-- Zvazit taku formu komunikacie, ktora je dostatocne rychla, postacuje na riesenie problemu ale je co mozno najjednoduchsia a ktora v pripade potreby umoznuje bez zmeny dva vyssie zmenene moduly oddelit na rozlicne pocitace. > Co by jste mi prosim doporucili? ^-- Neviem aky je rozsah projektu/problemu a tym padom rozpoctu, ale zvazil by som pouzitie SunOS (nativna platforma pre Javu, Real Time OS), samozrejme na Sparc architekture (na tento ucel asi nie T1, idealne UltraSPARC IV). Ale kedze program ma byt multiplatformovy, asi ma bezat vo viacerych instanciach, nie na "dedikovanom serveri", takze tento hint je asi irelevantny. J.
