Use of multiple WaitSets in one application?

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

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