You are here: Part 2: Core Concepts > Sending Data > Publisher/Subscriber QosPolicies > EXCLUSIVE_AREA QosPolicy (DDS Extension)

EXCLUSIVE_AREA QosPolicy (DDS Extension)

This QosPolicy controls the creation and use of Exclusive Areas. An exclusive area (EA) is a mutex with built-in deadlock protection when multiple EAs are in use. It is used to provide mutual exclusion among different threads of execution. Multiple EAs allow greater concurrency among the internal and user threads when executing Connext DDS code.

EAs allow Connext DDS to be multi-threaded while preventing threads from a classical deadlock scenario for multi-threaded applications. EAs prevent a DomainParticipant's internal threads from deadlocking with each other when executing internal code as well as when executing the code of user-registered listener callbacks.

Within an EA, all calls to the code protected by the EA are single threaded. Each DomainParticipant, Publisher and Subscriber represents a separate EA. All DataWriters of the same Publisher and all DataReaders of the same Subscriber share the EA of its parent. This means that the DataWriters of the same Publisher and the DataReaders of the same Subscriber are inherently single threaded.

Within an EA, there are limitations on how code protected by a different EA can be accessed. For example, when data is being processed by user code received in the DataReaderListener of a Subscriber EA, the user code may call the write() function of a DataWriter that is protected by the EA of its Publisher. So you can send data in the function called to process received data. However, you cannot create Entities or call functions that are protected by the EA of the DomainParticipant. See Exclusive Areas (EAs) for the complete documentation on Exclusive Areas.

With this QoS, you can force a Publisher or Subscriber to share the same EA as its DomainParticipant. Using this capability, the restriction of not being to create Entities in a DataReaderListener's on_data_available() callback is lifted. However, the trade-off is that the application has reduced concurrency through the Entities that share an EA.

Note that the restrictions on calling methods in a different EA only exists for user code that is called in registered Listeners by internal DomainParticipant threads. User code may call all Connext DDS functions for any Entities from their own threads at any time.

The EXCLUSIVE_AREA includes a single member, as listed in . For the default value, please see the API Reference HTML documentation.



Field Name




subordinates will not use the same EA

subordinates will use the same EA

The implications and restrictions of using a private or shared EA are discussed in Exclusive Areas (EAs). The basic trade-off is concurrency versus restrictions on which methods can be called in user, listener, callback functions. To summarize:

Behavior when the Publisher or Subscriber’s use_shared_exclusive_area is set to FALSE:

Behavior when the Publisher or Subscriber’s use_shared_exclusive_area is set to TRUE:


The code in Figure 26 illustrates how to change the EXCLUSIVE_AREA policy.

Figure 26 Creating a Publisher with a Shared Exclusive Area

DDS_PublisherQos publisher_qos;1Note in C, you must initialize the QoS structures before they are used, see Special QosPolicy Handling Considerations for C on page 1.
// domain, publisher_listener have been previously created
if (participant->get_default_publisher_qos(publisher_qos) !=
    // handle error
publisher_qos.exclusive_area.use_shared_exclusive_area = DDS_BOOLEAN_TRUE;
DDSPublisher* publisher = participant->create_publisher(publisher_qos,
    publisher_listener, DDS_STATUS_MASK_ALL);


This QosPolicy cannot be modified after the Entity has been created.

It can be set differently on the publishing and subscribing sides.

Related QosPolicies

This QosPolicy does not interact with any other policies.

Applicable DDS Entities

System Resource Considerations

This QosPolicy affects the use of operating-system mutexes. When use_shared_exclusive_area is FALSE, the creation of a Publisher or Subscriber will create an operating-system mutex.

© 2016 RTI