usando - do while c++ ejemplos resueltos

¿El ciclo While ilimitado ocupa los recursos de la CPU?

Question

Por lo que entiendo, usted escribe su Daemon de Linux que escucha una solicitud en un bucle sin fin.
Algo como..

int main() {
while(1) {
//do something...
}
}

ref: http://www.thegeekstuff.com/2012/02/c-daemon-process/

Leí que dormir en un programa lo hace entrar en modo de espera para que no consuma recursos.

1.Si quiero que mi demonio compruebe una solicitud cada 1 segundo, ¿consumiré lo siguiente?

int main() {
while(1) {
if (request) {
//do something...
}
sleep(1)
}
}

2.Si tuviera que eliminar el sueño, ¿significa que el consumo de CPU aumentará al 100%?

3. ¿Es posible ejecutar un bucle sin fin sin comer recursos? Decir ... si no hace nada más que solo hacer loops. O simplemente dormir (1).

Los bucles infinitos y los recursos de la CPU son un misterio para mí.

Answer 1

¿Es posible ejecutar un bucle sin fin sin comer recursos? Decir ... si no hace nada más que solo hacer loops. O simplemente dormir (1).

Hay una mejor opción.
Solo puede usar un semáforo , que permanece bloqueado al principio del bucle y puede señalar el semáforo cuando quiera que se ejecute el bucle.
Tenga en cuenta que esto no va a comer ningún recurso.

Answer 2

La respuesta corta es sí: eliminar el sueño da un 100% de CPU, pero la respuesta depende de algunos detalles adicionales. Consume todo el CPU que puede obtener, a menos que ...

1. El cuerpo del bucle es trivial, y optimizado de distancia.
2. El bucle contiene una operación de bloqueo (como un archivo o una operación de red). El enlace que proporciona sugiere evitar esto, pero a menudo es una buena idea bloquear hasta que suceda algo relevante.

EDITAR: Para su escenario, apoyo la sugerencia hecha por @Als.

EDIT 2: espero que esta respuesta haya recibido un -1 porque reclamo que las operaciones de bloqueo pueden ser una buena idea. [Si es -1, debería dejar una motivación en un comentario para que todos aprendamos algo.]

El pensamiento popular actual es que la IO sin bloqueo (basada en eventos) es buena y el bloqueo es malo. Esta vista se simplifica en exceso porque asume que todo el software que realiza IO puede mejorar el rendimiento mediante el uso de operaciones sin bloqueo.

¿Qué? ¿Realmente estoy sugiriendo que el uso de IO sin bloqueo realmente puede reducir el rendimiento? Sí puede. Cuando un proceso sirve para una sola actividad, en realidad es mejor usar el bloqueo de IO porque el bloqueo de IO solo quema los recursos que ya se pagaron en la existencia del proceso.

Por el contrario, la IO sin bloqueo puede tener una sobrecarga fija mayor que la simple IO con bloqueo. Si el proceso no puede proporcionar IO adicional que pueda intercalarse, entonces no se gana nada pagando por una configuración sin bloqueo. (En la práctica, el mayor costo de la E / S no bloqueadora inapropiada está simplemente en la complejidad del código agregado. Más allá de eso, este tema es en gran medida un ejercicio de reflexión).

Bajo el bloqueo de IO, dependemos del sistema operativo para programar los procesos que pueden progresar. Para eso está diseñado el sistema operativo.

Bajo IO sin bloqueo tenemos mayores costos de configuración, pero podemos compartir los recursos del proceso y sus hilos entre el trabajo intercalado. El IO sin bloqueo es ideal para cualquier proceso que sirva para múltiples actividades independientes, como un servidor web. El rendimiento obtenido es muy superior a los gastos generales fijos de la IO sin bloqueo.

Answer 3

Las poll y las llamadas de select (mencionadas por Basile Starynkevitch en un comentario) o un semáforo (mencionadas por Als en una respuesta) son las formas correctas de esperar solicitudes, según las circunstancias. En sistemas operativos sin poll o select , debería haber algo similar.

Ni sleep , YieldProcessor , ni sched_yield son formas adecuadas de hacer esto, por las siguientes razones.

YieldProcessor y sched_yield simplemente mueven el proceso al final de la cola ejecutable pero lo dejan ejecutable. El efecto es que permiten que se ejecuten otros procesos con la misma o mayor prioridad, pero, cuando esos procesos se llevan a cabo (o si no hay ninguno), el proceso llamado YieldProcessor o sched_yield continúa ejecutándose. Esto causa dos problemas. Una de ellas es que los procesos de menor prioridad aún no se ejecutarán. Otra es que esto hace que el procesador esté siempre funcionando, usando energía. Preferiríamos que el sistema operativo reconozca cuándo no es necesario que se ejecute ningún proceso y que el procesador se encuentre en un estado de bajo consumo.

sleep puede permitir este estado de baja potencia, pero juega un juego de adivinanzas sobre cuánto tiempo pasará hasta que llegue la próxima solicitud, despierta al procesador repetidamente cuando no es necesario y hace que el proceso sea menos sensible a las solicitudes, ya que el proceso continuará durmiendo hasta el vencimiento del tiempo solicitado, incluso si hay una solicitud para ser atendida.

Las poll y las llamadas de select están diseñadas exactamente para esta situación. Le dicen al sistema operativo que este proceso quiere atender una solicitud que llega en uno de sus canales de E / S, pero que por lo demás no tiene trabajo que hacer. Esto permite que el sistema operativo marque el proceso como no ejecutable y que ponga el procesador en un estado de bajo consumo, si corresponde.

El uso de un semáforo proporciona el mismo comportamiento, excepto que la señal para despertar el proceso proviene de otro proceso que eleva el semáforo en lugar de que surja actividad en un canal de E / S. Los semáforos son adecuados cuando la señal para hacer algún trabajo llega de esta manera; simplemente use cualquiera de las poll o un semáforo que sea más apropiado para su situación.

La crítica de que poll , select o un semáforo causa una llamada en modo kernel es irrelevante, porque los otros métodos también causan llamadas en modo kernel. Un proceso no puede dormir solo; Tiene que llamar al sistema operativo para solicitarlo. De manera similar, YieldProcessor y sched_yield realizan solicitudes al sistema operativo.