Wszyscy chcą mieć pule wątków

2011-03-10

Wygląda na to, że każda biblioteka w Javie (i nie tylko), która nawiązuje połączenia sieciowe lub uruchamia zewnętrzne programy nieuchronnie osiąga punkt, gdy autor stwierdza, że koniecznie trzeba napisać własne zarządzanie wątkami. I dostajemy różne ConnectionPools, ThreadManagers, ParallelExecutors i inne podobne. Pół biedy gdy da się je wyłączyć — ale nie zawsze jest to łatwe i nie zawsze się daje!

Dlaczego narzekam? Bo moim zdaniem strategia współbieżności powinna być określana na poziomie aplikacji, a nie biblioteki. Patrząc z poziomu aplikacji dokładnie wiem ile procesów/wątków chciałbym w tej chwili uruchomić, albo ile połączeń do bazy danych ma sens. Czasem jest tak, że koszt nowego połączenia jest niemal zerowy (jest tak np. z bazą Redis) i dla aplikacji WWW najbardziej niezawodnym rozwiązaniem jest otwieranie dokładnie jednego połączenia do bazy na jedno obsługiwane żądanie HTTP.

Gdy każda biblioteka próbuje definiować własne strategie wątkowania, otrzymujemy w pewnym momencie aplikację z wieloma pulami wątków o różnych przeznaczeniach, które zupełnie ze sobą nie współpracują. Gorzej — potrafią sobie nawzajem przeszkadzać. No i oczywiście takie opisy nie zachęcają (to z dokumentacji im4java):

One final warning: the code implementing the parallel processing of commands is new and therefore untested in the wild. During development, a number of race-conditions came up (and were solved), but feedback on stability, functionality and implementation is highly welcome.

Natrafiam na to szczególnie pisząc aplikację w Clojure, bo mając świetne narzędzia do ogarniania współbieżności w Clojure, nie chcę używać niczego innego i mało mnie interesuje wsparcie ze strony bibliotek.