Re[4]: [boost] Re: Boost.Thread: Wrapping NativeWindowsEventVariablespossible?

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-01-10 11:24:50

(Matthew Hurd <matt_at_[hidden]>) wrote:

> 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.  

I am not sure whether these two should be seen in the same light. You are normally
locking a mutex, because you need single exclusive access. You will not normally
have to block on more than one mutex, do you? Condvars on the other hand are
the tool to wait for any of a set of thing to become true. So I think this is the natural
abstraction to build on IO multiplexing. (aka async IO)

> In particular, asynch i/o and
> cancellable active objects have been mentioned, but many others spring to
> mind.  

What kind of `others` do you think of?
Cancellable active objects are feasible with the API that is already there.
You only have to store the condvar you are going to wait on in a global
(thread specific) location (your thread will at most be able to wait on a single
condvar at any time). When it comes to cancellation you you will need to set
a flag and signal this global condition. When exiting the wait, beneath the predicate
you simply test the flag and exit if requested. This all can be wrapped up into
an object to be transparent from the application. I did this by deriving from
condition a cancelable_condition class.

> 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.

As I already mentioned in a related post: The equivalent of boost using
notify or notify_all in OS terminology is on Windows to signal events.
This is escpecially true for async IO. I think one can see this equivalence up
to the point where you are supplying one and the same event object
to more than one async operation, and then wait for a single object. When
the event has been received you test the predicates by finding out which
outstanding operation has triggered it. Altough I did not test the following
it should go along the lines:

OVERLAPPED ov1, ov2;
HANDLE ev;
ev = CreateEvent(NULL, TRU, FALSE, NULL); // usage similar to a condvar
ov1.hEvent = ev;
ov2.hEvent = ev;

....

ReadFile(...., &ov1);
ReadFile(...., &ov2);
for (;;;) {
    // predicate testing
    if (GetOverlappedResult(.... &ov1, ... , FALSE) {
        // do something with it, e.g. dispatch it
       ReadFile(..., &ov1); // prepare next read operation
    }
    if (GetOverlappedResult(.... &ov2, ... , FALSE) {
        // do something with it, e.g. dispatch it
       ReadFile(..., &ov2); // prepare next read operation
    }
   // going to sleep again
   WaitForSingleObject(ev, INFINITE);
}

I am well aware, that the example is not semantically exact the same as 
using condvars, and also it likely has a bug as events are not queued as
conditions are. But I hope you can get the picture.

On posix I think select can be seen as a similar approach. But there
the Event does not show up explicitely, as it is implicit to select.

When it comes to consider possible interfaces I think in this
case one would need to differentiate 3 groups of usages:
1) Using boost to abstract from platform differences
    (very hard, because the topic can't be discussed without 
    creating a general IO abstraction, AFAIK the upcoming socket lib
    does no job on abstracting tty, tape, async fs operations, user ports,...)
2) Creating an interface for library writers (platform dependent hooks
    into boost.thread are sufficient)
3) Creating an interface for platform dependant code that is
    using boost also. (While I am not sure whether this is in the intended
    scope of boot at all, I think a similar solution as 2) might do.)
    
Anyways, I think also the possibility of emulation should be considered
either by a polled timeout approach or a thread per IO connection. 
While not beeing as efficient as possible this would give a playground
to experiment with different interfaces.

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

At least me is listening very eagerly.

Regards,
Roland