W jaki sposób Grand Central Dispatch naprawdę korzysta z systemu operacyjnego?

Question

Mam solidne pojęcie o działaniu GCD, ale chcę dowiedzieć się więcej o reklamowanych elementach wewnętrznych "zarządzania systemem operacyjnym". Wygląda na to, że prawie każde techniczne wytłumaczenie działania Grand Central Dispatch z "Systemem operacyjnym" jest zupełnie inne. Parafrazuję niektóre z moich ustaleń.

„Jest to demon, który jest globalny do systemu operacyjnego który rozdziela zadania przez wiele rdzeni.”

Nie jestem na tyle głupi, aby w to uwierzyć.

„Wsparcie jest wbudowana w jądro do być świadomy wszystkich zastosowań GCD. GCD aplikacje działają w porozumieniu z jądrem do podejmowania decyzji logicznych jak zarządzać wątki w aplikacji ”.

Wygląda na to, że ten schemat synchronizacji byłby znacznie wolniejszy niż zarządzanie logiką w aplikacji.

„GCD to istnieje wyłącznie w aplikacji i wykorzystuje obecny system obciążenie jako metryki, jak się zachowuje”.

Brzmi to bardziej realistycznie, ale widziałem tylko takie stwierdzenie w jednym miejscu.

Co się tutaj naprawdę dzieje? Czy to tylko biblioteka, czy też jest to cały "system"?

Answer 1

Jest to biblioteka, ale istnieją pewne optymalizacje jądra, aby umożliwić kontrolę poziomu systemu. W szczególności chodzi o to, że istnieje interfejs dodawania pthread_workqueue, który pozwala GCD na informowanie jądra, że ​​chce, aby wątek uruchomił jakąś określoną funkcję, ale tak naprawdę nie uruchamia wątku (jest to w zasadzie kontynuacja). W tym momencie jądro może wybrać rozpoczęcie tej kontynuacji w zależności od obciążenia systemu.

Tak, istnieje globalna ogólnosystemowa infrastruktura zarządzająca wątkami GCD w jądrze, a druga odpowiedź jest poprawna. Błędem, który popełniasz, jest myślenie, że trwa tam synchronizacja, która będzie coś kosztować. Program planujący będzie działał niezależnie od tego, co GCD wykonał, to nowy interfejs, który pozwala programistom nie tylko decydować, czy uruchomić wątki na podstawie ich względnego priorytetu, ale także czy tworzyć lub niszczyć wątki jako dobrze.

Jest to (znacząca) optymalizacja, ale nie jest to absolutnie konieczne, a port FreeBSD nie obsługuje w rzeczywistości całego systemu. Jeśli chcesz spojrzeć na rzeczywiste interfejsy, tutaj jest pthread_workqueue.h, implementacja znajduje się w Apple pthread.c, i można zobaczyć punkt wejścia, którego kernel używa do uruchamiania plików roboczych w ich ASM-ach w start_wqthread.s. Możesz także pobiegać poprzez xnu, aby zobaczyć, jak wskakuje do kikuta, jeśli naprawdę chcesz.