Nagłówek:
Threads.hpp
Elementy modułu:
Moduł Threads
- Obiektowy
- Przenośny
- W Windows używa WinAPI
- W Linux używa pthreads i jego rozszerzeń
- W razie błędów rzuca wyjątki modułu Error Ale wiele funkcji działających na już utworzonych obiektach (Lock, Wait itp.) dla optymalizacji wydajności nie sprawdza błędów.
- Wzorowany na:
- Korzysta z wzorca Pimpl. Dzięki temu nie wystawia do nagłówka żadnych zależności #include.
- Wydajność: Nie jest maksymalna (głównie przez ten Pimpl), ale nie powinna być zła.
Obiekty synchronizujące:
| Windows Linux
-----------+--------------------------------------------------------------------
Mutex | CRITICAL_SECTION lub Mutex pthread_mutex_t
Semaphore | Semaphore sem_t
Cond | (emulowany) pthread_cond_t
Barrier | (emulowany) pthread_barrier_t
Event | Event (emulowany)
- common::Thread: wątków Detached - wszystkie są Joinable. Dlaczego? Ponieważ nie chciało mi się tego pisać. Poza tym nie jest aż tak potrzebne.
- common::Thread: mechanizmu cancelacji Dlaczego? Bo szczegóły są zależne od danego problemu, zwykle to jest niepotrzebne i nie ma sensu zabierać czasu i pamięci na dodatkowe zasoby dla każdego wątku. Kto chce mieć cancelację, może sobie łatwo wstawić do klasy swojego wątku common::Event.
- Semafora binarnego Dlaczego? Bo nie ma go natywnie ani w WinAPI ani w pthreads. Poza tym nie jest aż tak potrzebny, no i nie chce mi się myśleć jak go zrobić.
- RW Lock Dlaczego? Bo to już bardziej zaawansowana sprawa, a ponadto zależna od konkregnego zastosowania. Nie zagłębiałem się w to jeszcze dokładnie.
- common::Event: PulseEvent Dlaczego? Bo nie jest to aż takie potrzebne - jest dziwne, a poza tym nie bardzo wiem jak to zasymulować w common::Event w Linuksie.
- Czekania z określoną zamiast niezdefiniowanej kolejnością wznawiania wątków.
- Zmienne warunkowe: Innych Signaling Disciplines niż Signal-and-Continue: np. Signal-and-Urgent-Wait, Signal-and-Exit, Urgent-Signal-and-Continue (wg książki "Modern Multithreading", Carver, Tai, wyd. Wiley, str. 199).