Musings

Dans mon dernier poteau j'ai discut� l'utilisation de WaitForSingleObject par rapport aux mutexes et aux mani�res possibles de mettre en application la fonctionnalit� �quivalente en mettant en communication un tel code � GNU/Linux.� Dans ce poteau je d�crirai l'utilisation de cet api avec des objets d'�v�nement dans Microsoft Windows et proposerai des mani�res possibles de signaler un tel code � GNU/Linux ou � Unix.

D'abord, un certain fond sur des objets d'�v�nement.� Un objet d'�v�nement est juste un autre type d'objet d'exp�diteur de grain de Windows.� D'un codage prespective, un objet d'�v�nement est un objet de synchronisation qui encapsule un ou plusieurs objets d'exp�diteur de grain et dont la s�mantique de synchronisation sont accessible par l'interm�diaire de WaitForSingleObject et de ses cousins.� � un moment donn� un objet de synchronisation nonsignaled ou est signal�, c.-�-d. l'objet peut seulement �tre dans un de deux �tats possibles.

Toute les famille de WaitFor des api comprenant l'attente de WaitForSingleobject sur une poign�e d'objet ou les poign�es jusqu'� quelques crit�res sp�cifiques est rencontr�e.� Les deux crit�res de base pour tous ces api sont l'�tat signal� de l'objet sur lequel la poign�e il attend et un valeur du d�passement de dur�e.� Ainsi un fil qui appelle des attentes de cet api jusqu'� ce que l'objet sp�cifique entre dans l'�tat signal� ou la temporisation sp�cifique a expir�.� Peu ou pas de temps- CPU est employ� quand un tel fil est dans l'�tat d'attente.

Dans le cas des �v�nements, un CreateEvent ou un OpenEvent renvoie une poign�e � un objet d'�v�nement.� Quand un �v�nement est dans l'�tat signal� il signifie que cela l'�v�nement a la capacit� de lib�rer un ou plusieurs fils attendant cet �v�nement particulier � signaler.� Quand un �v�nement est dans l'�tat nonsignaled il ne lib�rera aucun fil de attente.� Au commencement l'�tat d'un �v�nement nonsignaled.� Un �tat d'objet d'�v�nement est plac� explicitement � signaler par SetEvent ou PulseEvent.� Des objets d'�v�nement sont �galement employ�s dans des op�rations recouvertes telles que la lecture d'une douille, dans ce cas l'�tat d'objet d'�v�nement est plac� � signaler par le grain plut�t que par une application.

Les �v�nements viennent �galement dans deux types remis � z�ro.� Si un �v�nement est un �v�nement de manuel-remise, alors tout le retour de WaitForSingleObjects qui attendent cet �v�nement si ainsi configur�.� En d'autres termes un �v�nement de manuel-remise peut d�clencher l'action par un ou plusieurs WaitForSingleObject ou ses cousins.� Un �tat d'objet d'�v�nement de manuel-remise doit �tre remis � z�ro explicitement � nonsignaled par ResetEvent.

Pour un objet d'�v�nement de r�initialisation automatique, WaitForSingleObject et c'est des relations remis � z�ro

R�cemment j'ai �t� impliqu� en mettant en communication une application � 32 bits qui a �t� au commencement �crite pour le NT de Microsoft Windows � GNU/Linux.� Cette application a contenu un grand nombre d'appels � NtWaitForSingleObject et un plus petit nombre d'appels � NtWaitForMultipleObject.�

Maintenant quiconque qui a d� mettre en communication le code contenant plus que quelques exemples de ces api Win32 particuliers, ou leurs cousins �troits WaitForSingleObjectEx, MsgWaitForMultipleObjects, MsgWaitForMultipleObjectsEx, etc. � Unix ou GNU/Linux probablement frissonne d�j� avec le souvenir de longs jours et nuits laborieux du codage d'essai et des erreurs pour essayer et imiter correctement la s�mantique et la fonctionnalit� de ces api sp�cifiques particuliers de Microsoft Windows, mais pour le lecteur qui n'a pas encore d� essayer de mettre en communication une telle application, ce poteau et mon prochain poteau peut vous aider sauf votre sant� d'esprit (et probablement vos cheveux !) autrefois � l'avenir.

D'ailleurs, tous les deux api sont marqu�s ont d�sapprouv� dans MSDN par Microsoft mais travaillent toujours comme pr�vus dans Windows NT et Windows Xp.� Je ne suis pas s�r au sujet de Windows Vista ou de Windows 7 car je ne les ai pas examin�s sur ces logiciels d'exploitation.� Les deux api d�sapprouv�s ont �t� remplac�s par les api �quivalents WaitForSingleObject et WaitForMultipleObject respectivement.� Pour le reste de ce poteau je discuterai juste les api de remplacement mais plus de ce que je dis soyez valide pour d�sapprouv�e ou le remplacement api.

Au premier examen WaitForSingleObject semble assez b�nin.� La description dans MSDN d�clare que ��cette fonction retourne quand l'objet sp�cifique est dans l'�tat signal� ou quand l'intervalle de temporisation s'�coule��.� Ressemble � d'un api assez simple et innofensif, droite ?� Peut-�tre quelque chose semblable au pthread_cond_timedwait de POSIX.1 api.� Bien, vous avez compl�tement tort et ce poteau et ce qui suit expliqueront pourquoi.

WaitForSingleObject et ses cousins peuvent attendre un signal du quelques un ou tout des ��objets�� suivants : changez l'avis, l'entr�e de console, l'�v�nement, le travail, l'avis de ressource de m�moire, le mutex, le processus, la s�maphore, le fil et le temporisateur waitable et dans des circonstances limit�es sur les dossiers et l'entr�e-sortie de dossier.� Une fois convenablement signal�, un fil est d�gag� et continue.� Aucun api normalis� �dit� dans le monde de GNU/Linux ou d'Unix ne vient venu � manipuler cette gamme des objets dans un api simple.

C'est probablement l'un seul secteur o� un Win32 api mieux est con�u que l'ensemble de GNU/Linux ou d'Unix api.� � GNU/Linux et � Unix il y a des api sp�cifiques pour attendre diff�rentes sortes de