Vlákno názorů k článku Rychle, rychleji až úplně nejrychleji s jazykem Go od kvr - Na prvni pohled, podle examplu, mi prijde jako...
-
kvr (neregistrovaný)
Na prvni pohled, podle examplu, mi prijde jako hrozna slatanina. Proste vyvoj ve stylu, co by se nam tam jeste hodilo, tak to tam pridame, navic zjevne do toho mluvili znalci vsech jazyku. Vysledkem je prave zmatena syntaxe, casto nelogicke rozdeleni balicku apod.
Lehka vytka je naming convention, docela je vhodne drzet stejny interface na strane serveru i klienta, a tim, ze se v js bezne pouziva first lower case, tak kod v go nasledne bude vypadat dost nekonsistentne.
Inheritance bych tak nekritizoval. Je fakt, ze spousta vyvojaru ho dnes precenuje, ale jazyk bez jeji nativni podpory praci dost zkomplikuje.
Ad thread-locking u Map a jinych objektu – to je komplikovanejsi. Bud je tam vnitrni lockovani a pak je pekelne pomale (i kdyz nedojde ke kolizi), nebo je explicitne vynucene (viz thready v perlu – jde to, ale psat v tom je peklo – lockovani vsude, i kdyz je ocividne z hlediska designu zbytecne) nebo to zustava na vyvojari, s tim, ze kdyz neco neosetri, bude to padat jak shnile hrusky.
K rychlosti – ta srovnatelna rychlost s java ci interpretovanymi jazyky perl/php/python (doplnte svuj oblibeny) neni tak prekvapiva – stejne ten high-level kod neustale vola nativni, bylo by naivni ocekavat, ze se Go dokaze posunout nekam vyrazne dal.
Doufam, ze tohle upadne co nejdriv v zapomeni a pokud google nebude stacit C++/Java/perl/…, tak se nad tim zamysli jeste jednou a vytvori neco promyslenejsiho.
-
ondra.novacisko.cz (neregistrovaný)
Poznámka k lockování.
Lockování je _P_O_M_A_L_É_ . Sám jsem se to snažil ve svých knihovnách pořešit, ale skončil jsem u dvou možných závěrů:
1) Třídy, kde se předpokládá používání konkurence jsou většinou šablony, kde třída zámku je parametrem šablony (s předvyplněným NullLock, což je zámek-nezámek)
2) Neřešit to a používat plně oddělená vlákna.
Ten bod 2) je vlastně nejlepším řešením konkurence. Každé vlákno má svůj working set a pracuje jen se svými daty. S okolním světem komunikuje jen se zprávami zasílanými do front ostatních vláken. Tam jedině dochází k zámkům. A ty jsou velice krátké, často kritické sekce nebo spinlocky. Zpráva samotná také není zamykací, protože se předpokláda, že jí vlastní ten, který ji má ve frontě.
S ohledem na bod 2) jsem se na veškeré řešení konkurence vykašlal a lpím hodně na datovou oddělenost. Žádné globální objekty, nic podobného. A tam kde se bez toho neobejdu, tam platí bod 1)
-
Je to tak. Vyvoj jazyka Java to potvrzuje:
V Jave byly na zacatku tridy StringBuffer(modifikovatelny String) a Vector(list), ktere mely thread-safe metody. Pozdeji vsak byly pridany StringBuilder a ArrayList, ktere zamky nepouzivaji a jsou tak rychlejsi.
Ve skutecnosi malokdy potrebujete pristupovat k jedne instanci z vice vlaken. Teprve, kdyz jste ve vyjimecne situaci, ze to potrebujete, pouzijete nejakou mene beznou synchronizovanou tridu, ale pak casto zjistite, ze stejne potrebujete pod jednim zamkem zmenit vice objektu najednou a nevyhnete se explicitni synchronizaci.
Dokonce bych rekl, ze mapa je zrovna prikladem tridy kdy chete zamykat vetsi cast kodu:
synchronize(map){ value = map.get(key); if(value == null){ value = init(key); map.put(key, value); } return value; } -
podlesh (neregistrovaný)
Ještě bych doplnil, že existují neblokující datové struktury zajišťující bezpečný současný přístup. Místo zámků používají atomické operace typu compare-and-swap.
Konkrétně ve zmiňované Javě se jedná o java.util.concurrent.ConcurrentSkipListMap a java.util.concurrent.ConcurrentLinkedQueue
