[openamq-dev] Regarding amq_client_session_wait

blog blog at yankeeboysoftware.com
Wed Dec 19 11:53:06 CET 2007



On Wed, 2007-12-19 at 11:42 +0100, Martin Sustrik wrote:
> Hi,
> 
> I am not sure what your problem is. May you elaborate a bit? Are you 
> running OpenAMQ on a platform with cooperative multitasking, thus having 
> to yield control to other threads explicitly?
> 
> In fact, OpenAMQ is doing exactly the thing you've described, however, 
> the synchronisation object is hidden behind the API rather than exposed 
> to the client.

This is the problem: the call to amq_client_session_wait is a blocking
call.  Blocking calls prevent me from controlling my application.  How
do I cleanly interrupt the blocking call ?



> 
> Martin
> 
> blog wrote:
> > Use of amq_client_session_wait is troubling.
> > 
> > An application should not be bound in a tight loop checking for the
> > arrival of a message.  So, code like this is unsatisfying:
> > 
> > while(run)
> > {
> >   if (amq_client_session_wait (session, 0))
> >   {
> >     if (session->alive)    //  timeout expired
> >       yield(); // not a good idea
> >     else
> >       //  session died
> >       break;
> >   }
> >   else
> >   {
> >     //  zero or more contents arrived
> >   }
> > }
> > 
> > Equally troubling is a long timeout.  This would likely be implemented
> > in a thread which is either in a tight loop as above, or blocking
> > infinitely - which causes it's own problems.
> > 
> > The *preferred* solution is a to make use of a synchronization primitive
> > (preferably a named semaphore). This should be passed to the WireAPI in
> > the call to amq_client_session_wait, which should then return
> > asynchronously (immediately).  When a message arrives, the
> > synchronization object should become signaled.  This has the added
> > feature of allowing an application to easily and cleanly control worker
> > threads, since the application may signal the sync object to release the
> > thread from the wait.
> > 
> > This yields *nice* code as follows.
> > 
> > thread_func()
> > {
> >    semaphore sync("Unique_name");
> >    initialize_semaphore(sync, NOT_SIGNALED);
> >    amq_client_session_wait (session, sync); //non-blocking call
> > 
> >    semaphore_wait(sync);// blocks until signaled - very efficiently.
> >    if(amq_client_session_basic_arrived_count (session)) 
> >    {
> >      while (content && run)
> >      {
> >        //  process content
> >        content = amq_client_session_basic_arrived (session);
> >      }
> >    }
> >    else
> >    {
> >       // something else happened on the sync object
> >       // perhaps the app wants the thread to shutdown,
> >       // either way, we have fallen out of the blocking call
> >    }
> > }
> > 
> > Most modern Operating Systems will simply not schedule a timeslice for
> > any thread waiting on a non-signaled object.  This is far more efficient
> > than constant thread context switching to run a thread that is simply
> > going to call yield() (or sleep(0) - a poor equivalent) in a tight loop
> > waiting for a message to arrive.
> > 
> > For further reference please feel free to read 
> > http://www.yankeeboysoftware.com/wordpress/?p=15
> > 
> > _______________________________________________
> > openamq-dev mailing list
> > openamq-dev at lists.openamq.org
> > http://lists.openamq.org/mailman/listinfo/openamq-dev
> 
> _______________________________________________
> openamq-dev mailing list
> openamq-dev at lists.openamq.org
> http://lists.openamq.org/mailman/listinfo/openamq-dev



More information about the openamq-dev mailing list