La aplicación tiene un hilo auxiliar. Este hilo no debe ejecutarse todo el tiempo, pero el proceso principal puede llamarlo con mucha frecuencia.¿Mantener el hilo en espera es óptimo?
Entonces, mi pregunta es, ¿qué es más óptimo en términos de rendimiento de la CPU: suspender el hilo cuando no se usa o mantenerlo vivo y usar la función WaitForSingleObject para esperar una señal del proceso principal?
En términos de recursos de la CPU utilizadas, ambas soluciones son el mismo - el hilo que está suspendido y el hilo que está esperando en WaitForSingleObject para un objeto que no se señaliza tanto no obtiene ciclos de CPU en absoluto.
Dicho esto, WaitForSingleObject es casi siempre una solución preferida porque el código que lo usa será mucho más "natural" - más fácil de leer, y más fácil de hacer bien. La suspensión/reanudación de subprocesos puede ser peligrosa, porque debe tener mucho cuidado para asegurarse de saber que está suspendiendo un hilo en un estado en el que suspenderlo no causará daños (imagine suspender un hilo que actualmente contiene un mutex).
¿Qué quiere decir "suspender"? WaitForSingleObject suspenderá el hilo, es decir, no consumirá ninguna CPU, hasta que llegue la señal.
Si se trata de un subproceso de trabajo que tiene unidades de trabajo dadas externamente, definitivamente debe utilizar objetos de señalización, ya que eso asegurará que no use la CPU innecesariamente.
Si tiene algo de su propio trabajo que hacer, esa es otra cuestión. No suspendería el hilo de otro hilo (¿qué sucede si hay dos hilos entregando trabajo?) - mi regla básica es que los hilos deberían controlar su propia vida con sugerencias de otros hilos. Esto localiza todo el control en el hilo en sí.
Supongo que Andrei no usa Delphi para escribir .NET y, por lo tanto, Suspender no se traduce a System.Threading.Thread.Suspend pero a SuspendThread Win32 API.
Sugeriría encarecidamente que no lo haga. Si suspende el hilo en un momento arbitrario, entonces no sabe qué va a pasar (por ejemplo, puede suspender el hilo en tal estado que algún recurso compartido está bloqueado). Sin embargo, si ya sabe que el hilo está en estado suspensible, simplemente use WaitForSingleObject (o cualquier otra llamada WaitFor); será igualmente eficaz como suspender el hilo, es decir, el hilo utilizará un tiempo de CPU nulo hasta que se despierte.
Véase el excelente tutorial sobre multihilo en Delphi: Multi Threading Tutorial
Otra opción sería la TMonitor introdujo en Delphi 2009, que tiene funciones como la espera, el pulso y PulseAll para mantener hilos inactivo cuando no hay nada que hacer por ellos, y notificarles tan pronto como deberían continuar con su trabajo. Se modela libremente después de que el objeto se bloquea en Java. Al igual que allí, el objeto Delphi ahora tiene un campo de "bloqueo" que se puede usar para la sincronización de hilos.
Un blog que da un ejemplo de una clase de cola de rosca se puede encontrar en http://delphihaven.wordpress.com/2011/05/04/using-tmonitor-1/
desgracia, había un error en la implementación TMonitor, que parece estar fijo en XE2