Translate

Translate to EnglishÜbersetzen Sie zum Deutsch/GermanΜεταφράστε στα ελληνικά/GreekПереведите к русскому/RussianOversetter til Norsk/NorwegianÖversätta till Svensk/Swedishहिन्दी अनुवाद करने के लिए/Hindi
Tradueix al català/CatalanTulkot uz latviešu/LatvianPreložiť do slovenčiny/SlovakVertaal aan het Nederlands/Dutchترجمة الى العربية/ArabicTraduzca al Español/SpanishTraduisez au Français/French
Traduca ad Italiano/ItalianTraduza ao Português/Portuguese日本語に翻訳しなさい /Japanese한국어에게 번역하십시오/Korean中文翻译/Chinese Simplified中文翻译/Chinese TraditionalПереклад на українську/Ukrainian
Image of Linux Kernel Development (3rd Edition)
Image of XSLT 2.0 and XPath 2.0 Programmer's Reference (Programmer to Programmer)
Image of Modern Operating Systems (3rd Edition)
Image of RHCE Red Hat Certified Engineer Linux Study Guide (Exam RH302) (Certification Press)

Porting WaitForSingleObject to Linux – Part 2

In my last post I discussed the use of WaitForSingleObject in relation to mutexes and possible ways to implement equivalent functionality when porting such code to GNU/Linux.  In this post I will describe the use of this API with event objects in Microsoft Windows and suggest possible ways of posting such code to GNU/Linux or Unix.

First, some background on event objects.  An event object is just another type of Windows kernel dispatcher object.  From a coding prespective, an event object is a synchronization object which encapsulates one or more kernel dispatcher objects and whose synchronization semantics are accessable via WaitForSingleObject and its cousins.  At any given time a synchronization object is either nonsignaled or signaled, i.e. the object can only be in one of two possible states.

All of the WaitFor family of APIs including WaitForSingleobject wait on an object handle or handles until some specified criteria is met.  The two basic criteria for all these APIs are the signaled state of the object on whose handle it is waiting and a time-out value.  Thus a thread which calls this API waits till the specified object enters the signaled state or the specified time-out has expired.  Little or no CPU time is used when such a thread is in the wait state.

In the case of events, a CreateEvent or OpenEvent returns a handle to an event object.  When an event is in the signaled state it means that that the event has the capacity to release one or more threads waiting for this particular event to be signaled.  When an event is in the nonsignaled state it will not release any waiting thread.  Initially the state of an event is nonsignaled.  An event object’s state is set explicitly to signaled by SetEvent or PulseEvent.  Event objects are also used in overlapped operations such as reading from a socket, in which case the event object state is set to signaled by the kernel rather than by an application.

Events also come in two reset types.  If an event is a manual-reset event, then all WaitForSingleObjects return that wait for that event if so configured.  In other words a manual-reset event can trigger action by one or more WaitForSingleObject or its cousins.  A manual-reset event object’s state must be reset explicitly to nonsignaled by ResetEvent.

For an auto-reset event object, WaitForSingleObject and it’s relations reset the state

Porting WaitForSingleObject to Linux – Part 1

Recently I was involved in porting a 32-bit application which was initially written for Microsoft Windows NT to GNU/Linux.  This application contained a large number of calls to NtWaitForSingleObject and a smaller number of calls to NtWaitForMultipleObject. 

Now anybody who has had to port code containing more than a few instances of these particular Win32 APIs, or their close cousins WaitForSingleObjectEx, MsgWaitForMultipleObjects, MsgWaitForMultipleObjectsEx, etc. to Unix or GNU/Linux is probably already shuddering with the recollection of long arduous days and nights of trial and error coding to try and correctly mimic the semantics and functionality of these particular Microsoft Windows specific APIs, but for the reader who has not yet had to attempt to port such an application, this post and my next post may help you save your sanity (and possibly your hair!) sometime in the future.

By the way, both of these APIs are marked deprecated in MSDN by Microsoft but still work as expected in Windows NT and Windows XP.  I am not sure about Windows Vista or Windows 7 as I have not tested them on these operating systems.  The two deprecated APIs have been replaced by the equivalant APIs WaitForSingleObject and WaitForMultipleObject respectively.  For the remainder of this post I shall just discuss the replacement APIs but most of what I say will be valid for either the deprecated or the replacement API.

On first examination WaitForSingleObject seems fairly benign.  The description in MSDN states that “This function returns when the specified object is in the signaled state or when the time-out interval elapses”.  Sounds like a fairly simple and innocuous API, right?  Maybe something similar to the POSIX.1 API pthread_cond_timedwait.  Well, you are dead wrong and this post and the following will explain why.

WaitForSingleObject and its cousins can wait for a signal from any or all of the following “objects”: change notification, console input, event, job, memory resource notification, mutex, process, semaphore, thread and waitable timer and in limited circumstances on files and file I/O.  When appropriately signaled, a thread is unblocked and continues.  No published standardized API in the GNU/Linux or Unix world comes come to handling this range of objects in a single API.

This is probably the one single area where a Win32 API is better designed than the GNU/Linux or Unix API set.  In GNU/Linux and Unix there are specific APIs to wait for different kinds of events: