[Ace-users] [ace-users] Basic Reactor concepts

Douglas C. Schmidt schmidt at dre.vanderbilt.edu
Wed Feb 20 20:13:36 CST 2008


Hi Folks,

> I know this may be a heretical solution in an ACE group but..... you don't need (and shouldn't use) a Reactor for this
> problem.  But you'll need (at least) an ACE_Semaphore and an ACE_Mutex, so I guess I'm safe :)

I totally agree with Bob - you don't need a Reactor to implement this
sort of design.  A good reading of POSA2's Half-Sync/Half-Async chapter
will help set the record straight ;-)

Thanks,

        Doug

> Basically, I use a queue to service a thread pool.  Pretty standard stuff...when something goes into the queue, a Semaphore
> is kicked waking up a thread in the pool.  The queue is locked with a Mutex.  But the entries in the queue are queues
> themselves.  I won't go into all of the details, but the result looks like a Leader/Follower (the thread that wakes up
> pulls a queue out of the list of queues, then puts it back when done (if there are any entries left in the queue)).  It
> solves exactly the problem you're solving ... N queues and M threads.   N can grow and not affect M.
> 
> - Bob
> 
>                                                  To "'Gonzalo Diethelm'" <gonzalo.diethelm at diethelm.org>, "'Steve Huston'" 
>                                                     <shuston at riverace.com>                                                 
>                                                  cc ace-users at cse.wustl.edu                                                
> "Ganesh Pai" <ganeshpai at gmail.com>          Subject Re: [ace-users] Basic Reactor concepts                                 
> Sent by: ace-users-bounces at cse.wustl.edu                                                                                   
> 02/20/2008 04:57 PM                                                                                                        
> 
> One side effect of using one pipe per queue is that if the queues are
> unrelated when one thread/handler is processing one queue that handler is
> suspended from the reactor but other queues can be processed in parallel by
> other threads/handlers.
> 
> -----Original Message-----
> From: Gonzalo Diethelm [mailto:gonzalo.diethelm at diethelm.org]
> Sent: Wednesday, February 20, 2008 4:09 PM
> To: Steve Huston
> Cc: 'Ganesh Pai'; ace-users at cse.wustl.edu
> Subject: RE: [ace-users] Basic Reactor concepts
> 
> Excellent, thanks Steve. In fact, I am pretty sure this is exactly what
> I had done once, a long time ago, and also due to your suggestion; I
> believe this is what sounded to me similar to what Ganesh was proposing.
> 
> Two questions:
> 
> 1. Will this work with the TP_Reactor? I mean, when the strategy
> notifies the reactor, will all threads in the reactor eventually be used
> to handle the notifications?
> 
> 2. Will this work on Win32, with / without the TP_Reactor?
> 
> Thanks and best regards.
> 
> On Wed, 2008-02-20 at 15:59 -0500, Steve Huston wrote:
> > Check out ACE_Reactor_Notification_Strategy. There's also an
> > explanatory piece in the ACE Knowledge Base at
> > http://www.riverace.com/ace-kb.htm - search for "notifications"
> >
> > Best regards,
> > -Steve
> >
> > --
> > Steve Huston, Riverace Corporation
> > Want to take ACE training on YOUR schedule?
> > See http://www.riverace.com/training.htm
> >
> >
> > > -----Original Message-----
> > > From: ace-users-bounces at cse.wustl.edu
> > > [mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of Gonzalo
> > Diethelm
> > > Sent: Wednesday, February 20, 2008 3:41 PM
> > > To: Ganesh Pai
> > > Cc: ace-users at cse.wustl.edu
> > > Subject: Re: [ace-users] Basic Reactor concepts
> > >
> > >
> > > Thanks Ganesh. The approach you state rings a bell with me, I
> > > am sure I
> > > have done something similar. Could this be done without having the
> > > pipes, and only an event handler for each queue? The, when
> > > messages are
> > > deposited on the queue, could I achieve the same result by
> > > just calling
> > > reactor->notify(event_handler)? Or are the separate pipes a must?
> > >
> > > Thanks and best regards.
> > >
> > > On Wed, 2008-02-20 at 15:11 -0500, Ganesh Pai wrote:
> > > > Here is how I have solved this problem. This approach is
> > > for reactors based
> > > > on select/poll/epoll + Leader Follower pattern.
> > > >
> > > > * For each of the N queues, associate a pipe + event handler
> > > > * Plug the event handler into the reactor
> > > > * Using TP reactor you could then have M threads which run the
> > > >   Reactor loop
> > > > * Whenever messages are deposited into the queues, the associated
> > > >   pipe has to be notified
> > > > * One of the M threads would handle the pipe (handle_input)
> > > and process
> > > >   the message from the associated queue
> > > >
> > > > Hope this helps. The key to the above approach was the
> > > understanding that
> > > > select works only on some I/O handle. By associating a
> > > notification handle
> > > > (pipe) with each work queue makes the TP reactor now a
> > > de-multiplexer for
> > > > message queues as well.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: ace-users-bounces at cse.wustl.edu
> > > > [mailto:ace-users-bounces at cse.wustl.edu] On Behalf Of
> > > Douglas C. Schmidt
> > > > Sent: Wednesday, February 20, 2008 2:13 PM
> > > > To: Gonzalo Diethelm
> > > > Cc: ace-users at cse.wustl.edu
> > > > Subject: Re: [ace-users] Basic Reactor concepts
> > > >
> > > >
> > > > Hi Gonzo,
> > > >
> > > > > Again, I am trying to lessen my ignorance here...
> > > >
> > > > Always a laudable goal ;-)
> > > >
> > > > > Although I have always seen the Reactor as a key piece in
> > > the Acceptor
> > > > > / Connector / Svc_Handler class family in ACE, used to
> > > process I/O, a
> > > > > Reactor seems to be a generic concept for solving the following
> > > > > requirement, right?
> > > > >
> > > > > "Decouple the reception of events from its processing, in
> > > a way that,
> > > > > for instance, makes it possible to receive events in one
> > > thread and
> > > > > process them in a different thread".
> > > >
> > > > This is actually a different set of POSA2 patterns, e.g.,
> > > > Half-Sync/Half-Async or Active Object.  You should start by
> > reading
> > > > about them.  The Reactor pattern can be used as part of the
> > > > implementation of Half-Sync/Half-Async pattern.
> > > >
> > > > > Now, for me to understand this better, let me pose an
> > > example to you and
> > > > > maybe someone can indicate, if I am correct, how such an
> > > example would
> > > > > be handled with a Reactor. Say I have N message queues;
> > > they are all
> > > > > filled via some kind of opaque process which does not
> > > concern us, except
> > > > > for the fact that each queue is filled totally
> > > independent from the
> > > > > others (for example, one queue could store mouse events,
> > > another could
> > > > > store serial port incoming data, etc.). Now, I wish to
> > > have M threads
> > > > > (M != N) running in parallel, with an identical, simple
> > > infinite loop
> > > > > that will fetch an event from a queue that has signalled
> > > it has events
> > > > > available, and then process this event.
> > > > >
> > > > > If I am right in my assumptions about the Reactor's
> > > purpose in life,
> > > >
> > > > This isn't really the Reactor's purpose in life, unless
> > > those N queues
> > > > happen to be the appropriate type of OS handle than can be
> > > waited upon
> > > > together via a "synchronous event demuxer".
> > > >
> > > > > how do I wire things in this scenario in order to have
> > > the N queues
> > > > > use a Reactor to notify the M threads for processing?
> > > >
> > > > I think you're better off using the Half-Sync/Half-Async
> > > pattern here,
> > > > so please start by looking at it first.
> > > >
> > > > Thanks,
> > > >
> > > >         Doug
> > > >
> > > > _______________________________________________
> > > > ace-users mailing list
> > > > ace-users at mail.cse.wustl.edu
> > > > http://mail.cse.wustl.edu/mailman/listinfo/ace-users
> > > >
> > > >
> > >
> > > --
> > > Gonzalo Diethelm
> > > gonzalo.diethelm at diethelm.org
> > >
> > > _______________________________________________
> > > ace-users mailing list
> > > ace-users at mail.cse.wustl.edu
> > > http://mail.cse.wustl.edu/mailman/listinfo/ace-users
> > >
> >
> >
> >
> 
> --
> Gonzalo Diethelm
> gonzalo.diethelm at diethelm.org
> 
> _______________________________________________
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/ace-users
> 
> _______________________________________________________________________________________________________________
> This e-mail communication (and any attachment/s) may contain confidential or privileged information and is intended only
> for the individual(s) or entity named above and to others who have been specifically authorized to receive it. If you are
> not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please
> notify the sender that you have received this e-mail in error by reply e-mail, and delete the e-mail subsequently. Please
> note that in order to protect the security of our information systems an AntiSPAM solution is in use and will browse
> through incoming emails.
> Thank you.
> _________________________________________________________________________________________________________________
> 
> Ce message (ainsi que le(s) fichier(s)), transmis par courriel, peut contenir des renseignements confidentiels ou protŽgŽs
> et est destinŽ ˆ lÕusage exclusif du destinataire ci-dessus. Toute autre personne est, par les prŽsentes, avisŽe quÕil est
> strictement interdit de le diffuser, le distribuer ou le reproduire. Si vous lÕavez reu par inadvertance, veuillez nous en
> aviser et dŽtruire ce message. Veuillez prendre note qu'une solution antipollupostage (AntiSPAM) est utilisŽe afin
> d'assurer la sŽcuritŽ de nos systmes d'information et qu'elle furtera les courriels entrants.
> Merci.
> _________________________________________________________________________________________________________________
> 
> _______________________________________________
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/ace-users



More information about the Ace-users mailing list