A melhor prática é não pesquisar ... mas a pesquisa não está acontecendo internamente de qualquer maneira quando um thread chama wait ()?

Digamos que tenhamos um thread que deseja verificar quando outro thread termina sua tarefa. Eu li que devemos chamar uma função do tipo wait () que fará com que esse thread aguarde até receber uma notificação de que o outro thread foi concluído. E isso é bom porque significa que não estamos realizando pesquisas caras.

Mas as pesquisas não estão acontecendo internamente em um nível mais baixo? Ou seja, se fizermos o thread wait () o kernal não executar a pesquisa de qualquer maneira para verificar quando o outro thread for concluído, para que ele possa notificar o primeiro thread?

Presumo que estou perdendo algo aqui, alguém pode me esclarecer?

parallelism multithreading locks

— csss
fonte

O sistema operacional fornece certas primitivas para esse tipo de comunicação entre processos que não exigem pesquisa.

Se o processo A estiver aguardando no mutex M, o sistema operacional sabe que A não pode ser executado e o coloca de lado em um conjunto de processos aguardando que algo aconteça. Quando o processo segurando M o libera, o sistema operacional examina a lista de processos que o aguardam. O primeiro processo da lista, talvez A, é removido do intervalo inativo e colocado na fila de execução . Na próxima vez que A obtiver um intervalo de tempo, a espera () chamada retornará e o programa continuará.

— Blrfl
fonte

Então, de certa forma, ele está pesquisando, mas no nível do SO?

— tgkprog

Sem @tgkprog, isso não é pesquisa, porque o processo de espera não está programado para ser executado até que o SO ou outro processo libere o mutex. Um processo de pesquisa continuaria a competir no agendamento da CPU para verificar se deveria parar de esperar. Um processo de pesquisa desse tipo pode queimar uma parte substancial do tempo da CPU enquanto aguarda.

— Joshp # 30/13

eu quis dizer o processo do SO pesquisando o status do mutex. embora eu tenha certeza de que é otimizado e melhor do que qualquer coisa que possamos fazer. provavelmente é executado como parte do agendador.

— tgkprog 31/03

@tgkprog: O sistema operacional não presta muita atenção ao que está acontecendo com um mutex até que o processo que o segura o libere ou termine. Qualquer um desses eventos fará com que o sistema operacional entregue o bloqueio mutex para qualquer processo que esteja primeiro na lista de espera e marque esse processo como executável. Não há pesquisas envolvidas, apenas a resposta a um evento. Tudo o que Josué disse é incluído por referência. :-)

— Blrfl

@csss: Praticamente. Os processos podem terminar voluntariamente (por exemplo, chamando _exit(2)sistemas POSIX-y) ou involuntariamente (por exemplo, um erro como uma divisão por zero gera uma interrupção ou algo mais chama kill(2)). Em ambos os casos, o controle é explicitamente devolvido ao sistema operacional, que sabe qual processo estava em execução ou deve ser morto. O trabalho de finalizar um processo inclui liberar seus recursos, incluindo mutexes. Se um mutex foi mantido pelo processo agora morto, o sistema operacional o liberará. Se o processo estiver na lista de espera do mutex, ele será removido.

— Blrfl