RE: Re[2]: [boost] Re: Boost.Thread: Wrapping NativeWindowsEventVariablespossible?

From: Matthew Hurd (matt_at_[hidden])
Date: 2004-01-10 03:38:12

> On Behalf Of Sean Kelly

G'day Sean,

> On Thu, 8 Jan 2004, Hurd, Matthew wrote:
> >
> > The first idiom, of timed waiting and predicate checking, or something
> > else would still be required for active object cancellation where the
> > object is waiting on OS blocking things and you don't have a WFMO
> > equivalent though.
> >
> > Without a WFMO equivalent a boost implementation would have to:
> >
> >   1. block on each of them with a separate thread
> >   2. be able to stop the other waiting threads from waiting when one
> > fires.
> >
> > It is not pretty.
> >
> > So I think boost needs a portable interface to a WFMO equivalent.  Is
> > there an equivalent for POXIS, linux, solaris that is appropriate.
> > Perhaps a WFMO abstraction would be appropriate for asynch I/O?
> 
> Depends on the type of IO.  The only way to interrupt select() is to send
> data to a listening socket it's polling or close a socket it's polling.
> IIRC there is a way to signal IOCP to wake up though, I do it in the
> destructor of some of my comm. objects.

Closing the socket would not be acceptable, nor would be relying on sending
data, for many applications, so from what you say timeout is the way forward
for a select() kind of thing.

Does this thinking sound right?
 
> > A general implementation without direct OS support could have built with
> > timed blocking (very ugly) or cancelling threads (still very ugly just
> > less so from a performance viewpoint but perhaps more so from a
> > robustness viewpoint).  I don't think either of these are appropriate
> > options.
> 
> One slightly irritating feature of pthreads is that there's no supplied
> way to determine whether a thread has exited.  A suggested method to
> shutdown a thread might be to signal it and then join it, but IMO you
> would still want to have the wait for completion to time out as  I can
> think of a few instances where waiting indefinately for completion
> could cause problems.

I can see how cancelling threads can help model things if it can be done in
an appropriate manner, but I think it is much healthier to design thread
shutdown from the thread's point of view, which requires them being able to
react to a shutdown event, that is, not block indefinitely and loop checking
the shutdown flag, or some such.  Which, I think, is in line with what you
are saying...

> > Solving the cancellation with allow the messy solution of having various
> > threads blocked waiting for individual objects to work, but it is still
> > ugly and wasteful and should cause you to run a few miles in the
> > opposite direction.
> 
> If the thread loop is written correctly a timed wait isn't much of a
> performance hit, and in some cases the only workarounds are complex and
> error-prone.

Seems to be the way to go, but it can be a very significant performance hit
for some apps.  Waiting on multiple events, without a native WFMO
equivalent, will require a barrier to wait for all the child threads to
close themselves down.  You would then have signals from 0 to N of them.
Each time you do it you would cost you at least a timeout period, unless all
the waiters are signalled.

Any ideas on terminology... I'll have a think about bashing out some code.

Presently, we have mutexes and conditions in boost.  We want to add other
things that we can block on and wait for.  In particular, asynch i/o and
cancellable active objects have been mentioned, but many others spring to
mind.  This is a further abstraction from mutex but similar in most
interface requirements.  What about the name blocking_type, wait_type?  Is
there a common name?  Windows just calls them kernel objects.

The thread library has locks to block on mutexes.  Similarly we could wait,
timed_wait or try_wait.  Mutexes could be mapped, wrapped or changed to this
convention in addition to their normal interface.

The wait_for_mutiple_objects could then use some mpl magic to use an os WFMO
function, the timed out blocking, cancellable conditions or combinations of
such.  Kinda of a WFMO meta function...  The blocking_types would be WFMO
compatible, cancellable, or capable of timing out.  Any thing else make
sense?  I guess you could throw a polling type of blocking_type in there as
well which would be a misnomer so perhaps wait_type is a better concept
(active waiting ;-)).

This might provide a pattern for the orthogonal handling on asynch file and
socket i/o, polling, select, mutexes, condition variables, o/s timers and
the like.

Perhaps calling them all event_types is preferable.

>From this base you can define higher level constructs.  Such as a reactor
concepts, a model that works with boost::signals, perhaps with the nascent
fsm library in the sandbox, just callbacks, et cetera.

> Sean

Any interest or am I just whistling in the wind...

Regards,

Matt Hurd.