RE: Re[2]: [boost] Re: Boost.Thread: Wrapping Native WindowsEventVariables possible?

From: Hurd, Matthew (hurdm_at_[hidden])
Date: 2004-01-08 20:40:34

> On Behalf Of Roland
> Sent: Tuesday, 6 January 2004 11:37 PM
>
> Hi Matthew,
> 
> I am glad to read your post.
> I tried for several times to post a similar question than your
> "how do I shut down an active object that is blocked waiting...",
> but never got any response. Perhaps this time we can give
> new momentum to the discussion?

I use a timed block with a shutdown check.

This is from a message queue (that is not exception safe as it pops its
top in the wait_front).

        optional<T> wait_front() 
        {
            lock lk(monitor_);
            while ( list_.empty() && !shutdown_ ) {
 
not_empty_.timed_wait(lk,delay(0,default_timeout_milliseconds_));
            }
            return nothing_if_empty();
        }

        void notify_shutdown()
        {
            lock lk(monitor_);
            shutdown_ = true;
        } 

using these attributes:

typedef boost::mutex::scoped_lock lock; ///< the standard lock of the
class
boost::mutex monitor_;                  ///< mutex used for a monitor
idiom
boost::condition not_empty_;            ///< condition waiters wait on
... between timeouts
size_t default_timeout_milliseconds_;   ///< timeout for condition
variable locks
bool shutdown_;                         ///< true when object has been
notified of a shutdown

I think this is bad.  I think I should be blocking infinitely and change
my code to

        optional<T> wait_front() 
        {
            lock lk(monitor_);
            while ( list_.empty() && !shutdown_ ) {
                not_empty_.wait(lk);
            }
            return nothing_if_empty();
        }

        void notify_shutdown()
        {
            lock lk(monitor_);
            shutdown_ = true;

            // notify all waiters
            not_empty_.notify_all()
        }

I'll try that.

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.

> I think that your suggestion, altough beeing a workable soulution,
might
> be a bit
> too general. Do you really think it is necessary to be able to wait
for
> arbitrary multiple objects? Waiting for multiple objects in Windows
API is
> as
> I can understand basically a different (but semantically related)
concept
> to
> beeing able to wait on a single condition, and then test the (lock
> protected) predicates.

Not sure I'm following you here.  WMFO basically waits for one or all (a
flag) of several objects to be signalled.  MSDN indicates the following
objects can be waited upon:

  Change notification 
  Console input 
  Event 
  Job 
  Memory resource notification 
  Mutex 
  Process 
  Semaphore 
  Thread 
  Waitable timer

From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc
/base/waitformultipleobjects.asp

The original poster was using WFMO to wait on multiple io events.

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?

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.

> 
> >
> > This is a similar question to a simpler question of how do I shut
down
> an
> > active object that is blocked waiting...  Cancel the thread, timed
block
> > with shutdown condition check or wait for one of two signals.  I can
> only
> > see a solution with the second option within boost which is what I
> currently
> > use for my message and priority queues.
> 
> It is interesting to see that you are thinking that these problems are
> equivalent.
> I solved the first one (shuting down an object on which multiple
threads
> are
> blocked) entirely by building on top of the existing boost.thread API
by
> writing
> a cancelable_condition class that inherits from condition. This way I
also
> was
> able to write a cancelable_thread class, that is cancelable, as long
as a
> thread is blocked in a cond.wait(lk).
> 
> But I got stuck, because I cannot cancel the thread (or the object)
when
> it is
> blocked on IO. So solving the multiple wait problem would also solve
the
> cancellation problem. Or as you say the other way round solving
> cancellation
> would solve the multiple wait (altough I am not yet convinced about
this
> latter one).

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.

> >
> > Anyone see a better option?  Does posix provide a win32 WFMO
equivalent
> > boost can wrap?
> 
> All I know about is the select statement. But I do not know whether it
is
> Linux specific.
> Also I think it is only applyable to file descriptors.
> But I think that there could be some common ground: Concentrating on
file
> descriptors (posix)
> and Filehandles (Win32) and not trying to move over completely to
WFMO.

Dunno, a common abstraction to "things that might block" might be
healthy, regardless of what it is.  You want to be able to group them
together and least wait for one to signal, perhaps all.  This would give
you a nice active object design and an interface for asynch IO and
perhaps the start of a good reactor design...

Thoughts?

> Regards,
> Roland
> 
> BTW.: When I say "active object" I do not really speak about an object
> that has an embedded
> thread. I am speaking about the "Thread-safe Passive Object" <Monitor
> Object, Douglas C. Schmidt>

Hmmm, I'm talking about an active object that has its own thread or
thread pool, so perhaps we are talking about different things.  Tell me
to go away if you wish. 

Regards,

Matt Hurd.

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments.  Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited.  Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument.  Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.