Connext DDS Event and Receive threads may invoke user code through the Listener callbacks installed on different Entities while executing internal Connext DDS code. In turn, user code inside the callbacks may invoke Connext DDS APIs that reenter the internal code space of Connext DDS. For thread safety, Connext DDS allocates and uses mutual exclusion semaphores (mutexes).
As discussed in Exclusive Areas (EAs), when multiple threads and multiple mutexes are mixed together, deadlock may result. To prevent deadlock from occurring, Connext DDS is designed using careful analysis and following rules that force mutexes to be taken in a certain order when a thread must take multiple mutexes simultaneously.
However, because the Event and Receive threads already hold mutexes when invoking user callbacks, and because the Connext DDS APIs that the user code can invoke may try to take other mutexes, deadlock may still result. Thus, to prevent user code to cause internal Connext DDS threads to deadlock, we have created a concept called Exclusive Areas (EA) that follow rules that prevent deadlock. The more EAs that exist in a system, the more concurrency is allowed through Connext DDS code. However, the more EAs that exist, the more restrictions on the Connext DDS APIs that are allowed to be invoked in Entity Listener callbacks.
The EXCLUSIVE_AREA QosPolicy (DDS Extension) control how many EAs will be created by Connext DDS. For a more detailed discussion on EAs and the restrictions on the use of Connext DDS APIs within Entity Listener methods, please see Exclusive Areas (EAs).
© 2015 RTI