Administrace komentářů

Doporučuju se podívat na ExecutorService v Java. V zásadě je rozdělený na thread management a (nejlépe malé) user tasky, které provedou jasně daný úkol a skončí. Thread management si pak kontroluje přes eventy, zda je čas skončit. Technicky vzato, podporuje i interrupt, ale ten se obecně nedoporučuje, neboť asynchronní interrupt může napáchat dost škody, zvlášť, pokud jsou nějaké otevřené mutexy, semafory, conditions apod. Pokud by šlo o nějaký dlouhý "busy" task, tak sdílená proměnná může pomoct taky, u IO naopak poslat signal. Jenže pak už se ztrácí kouzlo rozdělení, kde za thread management je odpovědný ExecutorService a tasky jenom řeší malou úlohu. V Java to v zásadě funguje ještě dobře, neboť má (relativně) konsistentní návrh, jak se interrupted signal doručuje threadům, v C/C++ se to bude řešit hůř, neboť každý framework má jiný přístup (v zásadě jediná garance je návratová hodnota EINTR, atomický suspend signálu + pselect/ppoll/epoll, ale pořád je třeba nainstalovat správný signal handler atd).

Jinak k té volatile sdílené (nemusí být globální, to je prasárna) proměnné jako indikátoru ukončení - pominu-li jiné aspekty (zaseknutí na IO nebo sleep), tak ten volatile v zásadě fungovat bude, pokud její obsah bude v nějaké době doručen. Což dříve udělá jakákoliv architektura, v nejhorším případě poté, co bude vlákno přerušeno OS a systém invokuje memory barrieru. Volatile kompilátoru říká, že nesmí optimalizovat přístup paměti, takže i když nebude fungovat memory ordering, tak ta proměnná se tam časem zpropaguje a kód si ji přečte.

Není to ale bezpečné z důvodů výše - například thread čekající na další task z event queue, čekající na IO, si tu proměnnou nepřečte. Řešením je tedy poslat thread exit event skrz stejnou frontu, kterou posílá tasky, pro IO mít nějakou high-level konsistentní abstrakci nad tím, jak thready zpracovávají system signaly.