What are the strength and weaknesses of Richard Dengler's C++ emulation of WIN32's WaitForMultipleObjects using the pthreads library?

[Frank Chang]

I would like to know the strength and weaknesses of Richard Dengler's C++
emulation of WIN32's WaitForMultipleObjects using the pthreads library as
described in this URL, http://home.cablesurf.de/rdengler.

If I am not mistaken, Richard Dengler's emulation of WaitForMultipleObjects
is a hybrid between the event model when waiting for ANY event and the
fork-join model when waiting for ALL events.[EDIT, Please correct me if I
am wrong about this statement.]

Quoting from "Porting of Win32 API WaitFor to Solaris " by Nagendra
Nagarajayya and Alka Guptahttp in this URL:
madchat.fr/windoz/coding/winapi/waitfor_api.pdf,

A thread can wait for multiple objects to be set in one of two ways: 1. ALL
The issuing thread will unblock after ALL objects specified in the call
have been set. This is fairly simple to emulate. Each object is waited for
in turn until all have been set or until timeout occurs. At that point this
function returns.

   1.

   ANY The issuing thread will unblock after ANY one specified object in
   the call has been set

   WaitForMultipleObjects for the case ANY is the most difficult of all
   Win32 routines to emulate since UNIX does not support anything like it. The
   problem is that the issuing thread has to actually be blocked on a single
   Solaris variable, yet the setting of any one of a series of NT objects has
   to result in the signaling of that variable.[EDIT What does that mean in
   laymen's language?]

Following is a list of requirements for the solution:

   1.

   More than one thread could be waiting at any one time on same handle.
   2.

   Spurious signals may not be sent to threads. Note: For example, if
   thread 1 is waiting on two handles, A and B, and thread 2 is waiting on two
   handles A and C, and handle B is set, a signal may not be sent to thread 2
   just because it is waiting on handle A common to threads 1 and 2.
   3.

   No polling

The solution detailed in this paper makes use of the subscription model,
that is, the interested thread subscribes itself to the interested wait
object and goes to sleep until signaled.

The model proposes that each thread that issues or executes on a
WaitForcall on any one or more handles subscribes itself to those handles
by adding a pair of mutex/condition variable to that handle list and then
waits on that mutex/condition variable pair.

When a handle is set, all threads waiting on that handle are signaled.
Thus, if two threads wait on a handle, there will be two elements in the
list of that handle. And when the handle is set, both of the threads are
signaled.

LIMITATION

   1.

   Synchronized objects states are not modified. In other words, they are
   not non-signaled. [EDIT What is being said here?]
   2.

   Named handles require the handles to reside in shared space, and could
   be acted upon by other processes. This requires that the mutex and
   condition variables be created with system scope (the threads are already
   created with system scope). The shared space could be memory mapped on
   startup and shared by different processes.[EDTT Please explain this
   apparently important point.]
   3.

   Handles can be closed multiple times and need to be freed when the
   reference count goes to zero.
   4.

   There is no check for duplicate handles.
   5.

   Handle type is not checked.

   Finally, please show using C/C++ code the correct way to use Mr. Richard
   Dengler's port of WaitForMultipleObjects in an Ubuntu or Centos application
   program.

   Any help is greatly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20161011/5d1047ff/attachment.html>