std :: async - Użycie zależne od implementacji?

Question

Myślałem o std::async i jak należy go używać w przyszłej implementacji kompilatora. Jednak w tej chwili utknąłem w czymś, co wydaje mi się wadą projektu.

The std::async jest zależny od implementacji, z prawdopodobnie dwoma wariantami launch::async, jednym, który uruchamia zadanie w nowym wątku i takim, który używa puli wątków/harmonogramu zadań.

Jednak w zależności od jednego z tych wariantów, które są używane do implementacji std::async, użycie będzie bardzo różne.

Dla wariantu opartego na "puli wątków" można uruchomić wiele małych zadań, nie martwiąc się zbytnio o koszty ogólne, ale co, jeśli jedno z zadań blokuje w pewnym momencie?

Z drugiej strony wariant "uruchom nowy wątek" nie miałby problemów z blokowaniem zadań, z drugiej strony obciążenie związane z uruchamianiem i wykonywaniem zadań byłoby bardzo wysokie.

thread-pool: + nisko nad głową, -Nigdy kiedykolwiek blokowania

uruchamiają nowy wątek: + grzywny z bloków, -high napowietrznych

Więc zasadniczo w zależności od implementacji, sposób, w jaki używamy std::async, byłby bardzo ostrożny. Jeśli mamy program, który działa dobrze z jednym kompilatorem, może działać strasznie na innym.

Czy jest to zgodne z projektem? Czy może czegoś brakuje? Czy uznałbyś to, tak jak ja, za duży problem?

W obecnej specyfikacji brakuje czegoś takiego, jak std::oversubscribe(bool), aby umożliwić wdrożenie zależnego od siebie użycia std::async.

EDYCJA: O ile przeczytałem, standardowy dokument C++ 11 nie daje żadnych wskazówek dotyczących tego, czy zadania wysłane do std::async mogą blokować, czy nie.

Answer 1

std::async zadania uruchamiane z polityką std::launch::async metę „jakby w nowym wątku”, więc baseny wątek nie są naprawdę obsługiwane --- runtime musiałaby zburzyć i odtworzyć wszystkie zmienne lokalne w wątku między sobą wykonywanie zadań, co nie jest proste.

Oznacza to również, że można oczekiwać jednoczesnego uruchamiania zadań rozpoczętych przy użyciu zasady std::launch::async.Może pojawić się opóźnienie uruchomienia i nastąpi przełączanie zadań, jeśli masz więcej uruchomionych wątków niż procesorów, ale powinny działać, a nie zakleszczenie tylko dlatego, że ktoś czeka na innego.

Implementacja może zaoferować rozszerzenie, które pozwala na uruchamianie zadań w puli wątków, w takim przypadku to do tej implementacji jest udokumentowanie semantyki.

Answer 2

Spodziewam się, że implementacje uruchomią nowe wątki i pozostawią pulę wątków w przyszłej wersji C++, która je standaryzuje. Czy są jakieś implementacje, które używają puli wątków?

---

MSVC użył początkowo puli wątków w oparciu o ich Środowisko wykonawcze Współbieżności. Według STL Fixes In VS 2015, Part 2 zostało to usunięte. Specyfikacja C++ pozostawiła nieco miejsca dla programistów na robienie sprytnych rzeczy, ale nie sądzę, że pozostawia wystarczająco dużo miejsca na tę implementację łączenia wątków. W szczególności uważam, że specyfikacja nadal wymagała, aby obiekty thread_local zostały zniszczone i przebudowane, ale ta kombinacja wątków z ConcRT nie wspierałaby tego.