OpenDDS::DCPS::DataSampleListElement Struct Reference

#include <DataSampleList.h>

Collaboration diagram for OpenDDS::DCPS::DataSampleListElement:


Public Member Functions
	DataSampleListElement (PublicationId publication_id, TransportSendListener send_listner, PublicationInstance handle, TransportSendElementAllocator tse_allocator, TransportCustomizedElementAllocator tce_allocator)
	DataSampleListElement (const DataSampleListElement &elem)
DataSampleListElement &	operator= (const DataSampleListElement &elem)
	~DataSampleListElement ()
Public Attributes
DataSample *	sample_
PublicationId	publication_id_
	Publication Id used downstream.
CORBA::ULong	num_subs_
OpenDDS::DCPS::RepoId	subscription_ids_ [OpenDDS::DCPS::MAX_READERS_PER_ELEM]
DDS::Time_t	source_timestamp_
	Timestamp for the sample when it was first written.
DataSampleListElement *	previous_sample_
	Thread of all data within a DataWriter.
DataSampleListElement *	next_sample_
DataSampleListElement *	next_instance_sample_
	Thread of data within the instance.
DataSampleListElement *	next_send_sample_
	Thread of data being unsent/sending/sent/released.
DataSampleListElement *	previous_send_sample_
TransportSendListener *	send_listener_
bool	space_available_
	The flag indicates space availability for this waiting DataSample.
PublicationInstance *	handle_
TransportSendElementAllocator *	transport_send_element_allocator_
	Allocator for the TransportSendElement.
TransportCustomizedElementAllocator *	transport_customized_element_allocator_
	Allocator for TransportCustomizedElement.
GUIDSeq_var	filter_out_
	tracking for Content-Filtering data
std::map< DataLinkIdType, GUIDSeq_var >	filter_per_link_

Detailed Description

List elements include the marshaled message, the publication Id and Instance handle for downstream processing, and three separate threads allowing the elements to reside simultaneously on four different lists of data:

next_sample_ / previous_sample

the next sample of data in the DataWriter. This thread is used to traverse elements in the order in which they were written to the DataWriter (within PRESENTATION.access_scope==TOPIC). This thread will be used to hold the element in one of four different lists in the WriteDataContainer: the unsent_data_ list, the sending_data_ list, the sent_data_ list, or the released_data_ list at different times during its lifetime. This has a double link to allow removal of elements from internal locations in the list.

next_instance_sample_

the next sample of data in the instance within the DataWriter. This thread is used to traverse elements in the order in which they were written to the instance (within PRESENTAION.access_scope==INSTANCE). It is mainly used on the send side to count the depth of instance data and to allow the removal of elements by instance.

next_send_sample_/previous_send_sample_

the next sample of data to be sent. This thread is used external to the container to maintain a list of data samples that are to be transmitted over the transport layer. The Publisher may use this thread to maintain a list of samples to be sent with PRESENTATION.access_scope==GROUP by obtaining data from each DataWriter as it becomes available and concatentating the data in the order in which it was written.

We thread this single element rather than having multiple smaller lists in order to allow us to allocate once and have the element contained in all of the lists in which it will be held during its lifetime. These three threads will at times hold the element in three separate lists simultaneously. The next_sample_ thread will be used in the container to hold the element in one of three different lists at different times, so a single thread is all that is required for all of those lists.

NOTE: this is what we want to pass into the enqueue method of the container, since we want to centralize the allocation/deallocation so that we can minimize locking. By grabbing a single lock, allocating the buffer/Data_Block/Message_Block/DataSampleListElement at the same time, we only pay once for all of the allocations. They are all presumably from a cache (for the most part) anyway, so it should be fairly quick.

Constructor & Destructor Documentation

ACE_INLINE OpenDDS::DCPS::DataSampleListElement::DataSampleListElement	(	PublicationId	publication_id,
		TransportSendListener *	send_listner,
		PublicationInstance *	handle,
		TransportSendElementAllocator *	tse_allocator,
		TransportCustomizedElementAllocator *	tce_allocator
	)