Najlepszą praktyką jest nie sondowanie… ale czy sondowanie i tak nie odbywa się wewnętrznie, gdy wątek wywołuje funkcję wait ()?

Powiedzmy, że mamy wątek, który chce sprawdzić, kiedy inny wątek zakończy swoje zadanie. Przeczytałem, że powinniśmy wywołać funkcję typu wait (), która sprawi, że ten wątek zaczeka, aż otrzyma powiadomienie o zakończeniu drugiego wątku. I to jest dobre, ponieważ oznacza to, że nie przeprowadzamy drogich ankiet.

Ale czy i tak ankietowanie nie odbywa się wewnętrznie na niższym poziomie? Czyli jeśli sprawimy, że wątek zaczeka (), jądro i tak nie wykonuje odpytywania, aby sprawdzić, kiedy drugi wątek jest zakończony, aby mógł następnie powiadomić pierwszy wątek?

Przypuszczam, że coś tu brakuje, czy ktoś może mnie oświecić?

parallelism multithreading locks

— csss
źródło

System operacyjny zapewnia pewne operacje podstawowe dla tego rodzaju komunikacji międzyprocesowej, które nie wymagają odpytywania.

Jeśli proces A czeka na muteksie M, system operacyjny wie, że nie można go uruchomić i odkłada go na bok procesów oczekujących na coś. Po zwolnieniu go przez proces o numerze M system operacyjny sprawdza listę oczekujących na niego procesów. Pierwszy proces na liście, być może A, jest usuwany z nieużywanego segmentu i umieszczany w kolejce uruchamiania . Następnym razem, gdy A otrzyma wycinek czasu, wywołanie wait () zwróci i program będzie kontynuował.

— Blrfl
źródło

więc w pewnym sensie jest to odpytywanie, ale na poziomie systemu operacyjnego?

— tgkprog

Nie @tgkprog, to nie jest odpytywanie, ponieważ proces oczekiwania nie jest zaplanowany do uruchomienia, dopóki system operacyjny lub inny proces nie zwolni muteksu. Proces odpytywania będzie nadal konkurował w planowaniu procesora, aby sprawdzić, czy powinien przestać czekać. Proces odpytywania tego rodzaju może spalić znaczną część czasu procesora podczas oczekiwania.

— joshp

miałem na myśli, że proces systemu operacyjnego odpytuje status muteksu. chociaż jestem pewien, że jest zoptymalizowany i lepszy niż cokolwiek, co moglibyśmy zrobić. prawdopodobnie działa jako część harmonogramu.

— tgkprog

@tgkprog: System operacyjny nie zwraca uwagi na to, co dzieje się z muteksem, dopóki proces trzymający go nie zwolni go lub nie zakończy. Każde z tych zdarzeń spowoduje, że system operacyjny włączy blokadę mutex do dowolnego procesu, który jest pierwszy na liście oczekujących, i oznaczy ten proces jako uruchamialny. Nie ma potrzeby przeprowadzania ankiet, tylko reakcja na zdarzenie. Wszystko, co powiedział joshp, jest włączone przez odniesienie. :-)

— Blrfl

@csss: Prawie. Procesy mogą kończyć się dobrowolnie (np. _exit(2)Wywoływanie w systemach POSIX-y) lub mimowolnie (np. Błąd taki jak dzielenie przez zero generuje przerwanie lub coś innego wywołuje kill(2)). W obu przypadkach kontrola jest wyraźnie przekazywana z powrotem do systemu operacyjnego, który wie, który proces był uruchomiony lub ma zostać zabity. Zadanie zakończenia procesu obejmuje uwolnienie jego zasobów, w tym muteksów. Jeśli muteks był przetrzymywany przez nieżywy proces, system operacyjny go zwolni. Jeśli proces był na liście oczekujących mutexów, zostanie on usunięty.

— Blrfl