La mejor práctica es no sondear ... pero, de todos modos, ¿no es el sondeo interno cuando un hilo llama a wait ()?

Digamos que tenemos un hilo que quiere verificar cuando otro hilo termina su tarea. He leído que deberíamos llamar a una función de tipo wait () que hará que este hilo espere hasta que reciba una notificación de que el otro hilo ha terminado. Y eso es bueno porque significa que no estamos realizando encuestas costosas.

Pero, de todos modos, ¿las encuestas no se realizan internamente en un nivel inferior? Es decir, si hacemos que el hilo espere (), ¿no está el kernel realizando un sondeo de todos modos para verificar cuándo el otro hilo está terminado para que luego pueda notificar al primer hilo?

Supongo que me estoy perdiendo algo aquí, ¿alguien puede iluminarme?

parallelism multithreading locks

— csss
fuente

El sistema operativo proporciona ciertas primitivas para este tipo de comunicación entre procesos que no requieren sondeo.

Si el proceso A está esperando en el mutex M, el sistema operativo sabe que A no se puede ejecutar y lo deja a un lado en un grupo de procesos que esperan que ocurra algo. Cuando el proceso que contiene M lo libera, el sistema operativo mira la lista de procesos que lo esperan. El primer proceso de la lista, quizás A, se elimina del depósito inactivo y se pone en la cola de ejecución . La próxima vez que A obtenga un intervalo de tiempo, la espera () que llamó volverá y el programa continuará.

— Blrfl
fuente

entonces, en cierto modo, está sondeando pero a nivel del sistema operativo?

— tgkprog

No @tgkprog, esto no es sondeo, porque el proceso de espera no está programado para ejecutarse hasta que el sistema operativo u otro proceso libere el mutex. Un proceso de votación continuaría compitiendo en la programación de la CPU para verificar si debería dejar de esperar. Un proceso de sondeo de este tipo puede quemar una parte sustancial del tiempo de CPU mientras espera.

— joshp

Me refería al proceso del SO que sondeaba el estado de mutex. aunque estoy seguro de que está optimizado y mejor que cualquier cosa que podamos hacer. probablemente se ejecuta como parte del planificador.

— tgkprog

@tgkprog: el sistema operativo no presta un poco de atención a lo que sucede con un mutex hasta que el proceso que lo contiene lo libera o finaliza. Cualquiera de esos eventos hará que el sistema operativo entregue el bloqueo de mutex a cualquier proceso que esté primero en la lista de espera y marque ese proceso como ejecutable. No hay encuestas involucradas, solo respuesta a un evento. Todo lo que joshp dijo está incluido por referencia. :-)

— Blrfl

@csss: más o menos. Los procesos pueden finalizar voluntariamente (por ejemplo, llamando _exit(2)a los sistemas POSIX-y) o involuntariamente (por ejemplo, un error como una división por cero genera una interrupción o algo más llama kill(2)). En cualquier caso, el control se devuelve explícitamente al sistema operativo, que sabe qué proceso se estaba ejecutando o qué se debe matar. El trabajo de finalizar un proceso incluye liberar sus recursos, incluidos mutexes. Si el proceso ahora inactivo retuvo un mutex, el sistema operativo lo liberará. Si el proceso estaba en la lista de espera de mutex, se eliminará.

— Blrfl