Musings

En mi poste pasado discut� el uso de WaitForSingleObject en lo referente a mutexes y a maneras posibles de ejecutar funcionalidad equivalente al virar tal c�digo hacia el lado de babor a GNU/Linux.� En este poste describir� el uso de este API con los objetos del acontecimiento en Microsoft Windows y sugerir� maneras posibles de fijar tal c�digo a GNU/Linux o a Unix.

Primero, un cierto fondo en objetos del acontecimiento.� Un objeto del acontecimiento es apenas otro tipo de objeto del despachador del n�cleo de Windows.� De una codificaci�n prespective, un objeto del acontecimiento es un objeto de la sincronizaci�n que encapsula uno o m�s objetos del despachador del n�cleo y cuya sem�ntica de la sincronizaci�n es accesible v�a WaitForSingleObject y sus primos.� En un momento dado un objeto de la sincronizaci�n nonsignaled o se se�ala, es decir el objeto puede solamente estar en uno de dos estados posibles.

Toda la familia de WaitFor de APIs incluyendo la espera de WaitForSingleobject en una manija del objeto o las manijas hasta algunos criterios especificados se resuelve.� Los dos criterios b�sicos para todos estos APIs son el estado se�alado del objeto en cuya manija est� esperando y un valor del time out.� As� un hilo de rosca que llama esperas de este API hasta que el objeto especificado incorpora el estado se�alado o el descanso especificado ha expirado.� Se utiliza poco o nada de tiempo CPU cuando tal hilo de rosca est� en el estado de espera.

En el caso de acontecimientos, un CreateEvent o un OpenEvent vuelve una manija a un objeto del acontecimiento.� Cuando un acontecimiento est� en el estado se�alado significa que �se el acontecimiento tiene la capacidad de lanzar uno o m�s hilos de rosca que esperan este acontecimiento particular que se se�alar�.� Cuando un acontecimiento est� en el estado nonsignaled no lanzar� ningún hilo de rosca que espera.� El estado de un acontecimiento nonsignaled inicialmente.� Un estado de objeto del acontecimiento es fijado expl�citamente a se�alado por SetEvent o PulseEvent.� Los objetos del acontecimiento tambi�n se utilizan en operaciones traslapadas tales como lectura en un z�calo, en este caso el estado de objeto del acontecimiento es fijado a se�alado por el n�cleo algo que por un uso.

Los acontecimientos tambi�n vienen en dos tipos reajustados.� Si un acontecimiento es un acontecimiento del manual-reajuste, despu�s toda la vuelta de WaitForSingleObjects que espera ese acontecimiento si est�n configurado tan.� Es decir un acontecimiento del manual-reajuste puede accionar la acci�n por uno o m�s WaitForSingleObject o sus primos.� Un estado de objeto del acontecimiento del manual-reajuste se debe reajustar expl�citamente a nonsignaled por ResetEvent.

Para un objeto del acontecimiento del auto-reset, WaitForSingleObject y es relaciones reajustado

Estuve implicado recientemente en virar un uso hacia el lado de babor de 32 bits que fue escrito inicialmente para el NT de Microsoft Windows a GNU/Linux.� Este uso contuvo una gran cantidad de llamadas a NtWaitForSingleObject y un n�mero m�s peque�o de llamadas a NtWaitForMultipleObject.�

Ahora cualquiera que ha tenido que virar el c�digo hacia el lado de babor que conten�a m�s que algunos casos de estos APIs particulares Win32, o sus primos cercanos WaitForSingleObjectEx, MsgWaitForMultipleObjects, MsgWaitForMultipleObjectsEx, etc. a Unix o GNU/Linux probablemente se est� estremeciendo ya con el recuerdo de d�as y de noches arduos largos de la codificaci�n de ensayo y de error para intentar y para m�mico correctamente la sem�ntica y la funcionalidad de estos APIs espec�ficos particulares de Microsoft Windows, pero para el lector que todav�a no ha tenido que intentar virar tal uso, este poste y mi poste hacia el lado de babor siguiente puede ayudarle excepto su cordura (y posiblemente su pelo!) alguna vez en el futuro.

A prop�sito, ambos APIs se marcan desaprobaron en MSDN de Microsoft pero todav�a trabajan seg�n lo esperado en Windows NT y Windows Xp.� No estoy seguro sobre Windows Vista o Windows 7 pues no los he probado en estos sistemas operativos.� Los dos APIs desaprobados han sido substituidos por los APIs equivalentes WaitForSingleObject y WaitForMultipleObject respectivamente.� Para el resto de este poste apenas discutir� los APIs del reemplazo pero la mayor parte de qu� digo sea v�lido para haber desaprobado o el reemplazo API.

En la primera examinaci�n WaitForSingleObject parece bastante benigno.� La descripci�n en MSDN indica que esta funci�n vuelve cuando el objeto especificado est� en el estado se�alado o cuando transcurre el intervalo del descanso.� �Suena como un API bastante simple e inofensivo, la derecha?� Quiz� algo similar al pthread_cond_timedwait de POSIX.1 API.� Bien, usted es absolutamente incorrecto y este poste y lo que sigue explicar�n por qu�.

WaitForSingleObject y sus primos pueden esperar una se�al de lo que sea de los objetos siguientes: cambie la notificaci�n, la entrada de la consola, el acontecimiento, el trabajo, la notificaci�n del recurso de memoria, el mutex, el proceso, el sem�foro, el hilo de rosca y el contador de tiempo waitable y en circunstancias limitadas en archivos y la entrada-salida del archivo.� Cuando est� se�alado apropiadamente, un hilo de rosca se desbloquea y contin�a.� Ningún API estandardizado publicado en el mundo de GNU/Linux o de Unix viene venido a manejar esta gama de objetos en un solo API.

�sta es probablemente la una sola �rea donde un Win32 API se dise�a mejor que el sistema de GNU/Linux o de Unix API.� En GNU/Linux y Unix hay APIs espec�ficos para esperar diversas clases de