Use of multiple WaitSets in one application?

4 posts / 0 new
Last post
Offline
Last seen: 7 years 8 months ago
Joined: 10/21/2012
Posts: 18
Use of multiple WaitSets in one application?

Hello,

Many applcations in our system use WaitSets to detect various DDS conditions, and react accordingly.  At this stage, most, if not all, use a single WaitSet.

Are there any performance issues that one should be aware of before introducing a second WaitSet, with a different set of conditions attached, into an application?

My initial guess is that the extra WaitSet would mean at least one extra thread in the application.  But is there anything else?

Thanks in advance

Dallas

Organization:
Keywords:
Gerardo Pardo's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 06/02/2010
Posts: 602

Hello,

I would not expect performance degradations from using multiple WaitSets. perhaps a bit more resource usage but you should see enhanced performance from being able to get concurrency in processing whatever you are waiting for on the WaitSet..

As you probably know the WaitSet itself does not create internal threads. What the WaitSet mostly contains is a signaling semaphore and a linked list to the attached conditions. The Semaphore is used by the conditions to "wakeup" the any thread that may be waiting on the waitset. However as you stated in order to wait on two different waisets simultaneously you would need two separate threads.

In most operating systems threads are pretty light weight, specially if you reuse them rather than create/delete them all the time. In other words the pattern of creating a new thread to process each new event from the WaitSet would have low performance, of course, but a pattern where there is a thread pool  of pre-created threads and you pick from this to have one waiting on each WaitSet should get you better performance on a multi-core processor than having a single thread on a single WaitSet. This is what we do in serveral of our services like Routing Service or Queing Service.

Gerardo

Offline
Last seen: 7 years 8 months ago
Joined: 10/21/2012
Posts: 18

Thanks Gerado,

In our system, the WaitSets we create tend to be created once and used for the life of the application, often in their own thread, and use either boost or Qt signals to notify and pass data to the rest of the application when necessary.

If we were to create a second similar thread with its own WaitSet in our applications, it looks like the performance penalty would be minimal, but a few extra resouces would be needed for the extra thread.  I think we can live with that.

Dallas

asanchez's picture
Offline
Last seen: 4 years 1 month ago
Joined: 11/16/2011
Posts: 50

Hi Dallas,

I'd like to answer to your question first and then talk about a new feature RTI is currently working on that may be strongly related to your use case.


As Gerardo well mentioned, introducing an additional WaitSet should minimally increase resources with no performance penalty. In fact, performance could increase as of the consequent increment in concurrency; while a thread is blocked processing a Condition (e.g. writing data) another thread could be processing any other condition (e.g. reading data).


You've mentioned several times that adding a WaitSet would imply a new thread. In fact the usage of a WaitSet is tightly coupled with the requirement of a separate thread in charge of waiting on that WaitSet and properly dispatching the events represented by the active Conditions. The ultimate goal could be to have a single WaitSet and a pool of threads that can be dynamically used to perform the WaitSet wait and processing.

This behavior is generic enough and agnostic to the specifics of an application domain thus a generic component could encapsulate it. This what RTI is aiming with a potential new feature that consists of a new API component that we are calling today as Asynchronous WaitSet (AWS). The AWS simpley extends the concept of a WaitSet so that the wait and dispatch is handled by a pool of threads, whose size can be specified by the user. The API would look something like this:

 

//instantiates an AWS with default settings (e.g. thread pool size = 1).
AsyncWaitSet aws;	

//The handler is a virtual class that handles the condition. Implementation is provided by the user.
StatusCondition cond = reader.status_condition().handler(myHandler); 

//similar to the WaitSet::attach_condition()
aws.attach_condition(cond); 

// creates the thread pool and start waiting for events and dispatch them
aws.start();	

I believe this would fit well your use case and provide the behavior you need out of the box. We'd be more than happy to hear any feedback from you regarding this API.

Best,

Antonio