Best regards,
Sergey

My variables are located in a shared memory. Writer and readers run in different processes.Critical sections are not an interprocess primitives. Second, critical sections are not effective in a single-writer-multiple-readers tasks.

So, I had a choice: implement swmr-interprocess critical section, or think up something simpler for this particular (and similar) tasks...

Your initial statement was "...fromdifferent threads...". It wasn't clear that aWriter and Readers are working
in different processes. Thanks for clarification.

Sorry, when I wrote the post, then focused on the out-of-order execution, not the nuances of use. Code above is a sample only and is intended for better understanding. I am interested in the out-of-order executionprinciple itself.

a) The writer could write multiple times before a reader could read. Eeven though you have multiple readers and the chance is low for this to happenit will still happen. Possible causes for missed reads (or bunged up data) are: Process time for all readers exceed production time forwriter. Reader threads get preempted or suspended (e.g.page file expansion, I/O block time, etc...).This causes missed packets.

b) The writer could begin a second write while the reader is in the process of reading the prior write. This cause bunged up data packets.

c) Multiple threads could have read the same or bunged up packet.

The code example I provided earlier avoids these issues.

Using a critical section is heavier weight. However, a critical section does contain a SpinWait, which in this case does you no good (you have a polling structure).

To incorporate thread suspension, you will need to use a condition variable in Linux or Event in Windows. This will add overhead in the writer and latency/overhead in the reader. Since you state your write rate is at relativelylong intervals, it would seem like use of condition variable or event should be investigated. Note, if you are using a threading toolkit, it may have alternate means to trigger (enqueue) a reader task.

Jim Dempsey

I understand that under the concept of "bunged up" you mean lost (no one read) messages, not the a-b-c-d data inconsistency. So:

a) It is correct by design.

b) It is correct by design.

c) It is correct by design.

Do you even read my last response to you?I am interested in aout-of-order processorexecution principle, not in particular data exchange model.

I found rules of the game! Intel Architectures Software Developer's Manual, Volume 3,Chapter multiple-processor
management, memory ordering: 1.Neither Loads Nor Stores Are Reordered with Like Operations 2.Stores Are Not Reordered With Earlier Loads 3.Loads May Be Reordered with Earlier Stores to Different Locations 4. ... etc ... Thanks to everyone who took part in the discussion!

a(at t=1), b(at t=1), c(at t=2), d(at t=2)

The above would occue if thet=2 write occured while reader waspart way through the read of t=1 packet.

To protect from the situation you described,m_vers1/m_vers2 variables are used. Ifa(at t=1), b(at t=1), c(at t=2), d(at t=2), then vers2 will not be equal to vers1. Therefore, Reader will do one more (or several) iteration of the loop, till the data consistency: a(at t=N), b(at t=N), c(at t=N), d(at t=N)and, of course,vers1(at t=N), vers2(at t=N).

Yes, I want to avoid the use of synchronization primitives. For this task, I think they are redundant.

By the way, I learned that the instructions prefixed with lock (which are used within a critical section), are also amemorybarrier (Intel Architectures Software Developer's Manual, Volume 3). And thus guarantee the correct order of execution.

Yes, I want to avoid the use of synchronization primitives. For this task, I think they are redundant.

By the way, I learned that the instructions prefixed with lock (which are used within a critical section), are also amemorybarrier (Intel Architectures Software Developer's Manual, Volume 3). And thus guarantee the correct order of execution.

Thinking further, I came to conclusion: in order to insure against the misunderstanding of my intentions by the compiler, codecan be modified like this:

class X

{

protected:

	volatile DWORD m_vers1;

	volatile DWORD m_a;

	volatile DWORD m_b;

	volatile DWORD m_c;

	volatile DWORD m_d;

	volatile DWORD m_vers2;
public:

	X()

		: m_vers1( 0 )

		, m_vers2( 0 )

	{}
	void Write( DWORD a, DWORD b, DWORD c, DWORD d )

	{

		_InterlockedIncrement( reinterpret_cast< volatile LONG* >( &m_vers2 ) );
		m_a = a;

		m_b = b;

		m_c = c;

		m_d = d;
		_InterlockedIncrement( reinterpret_cast< volatile LONG* >( &m_vers1 ) );

	}
	void Read( DWORD& ra, DWORD& rb, DWORD& rc, DWORD& rd )

	{

		for ( ;; )

		{

			DWORD vers1 = (DWORD)_InterlockedCompareExchange( reinterpret_cast< volatile LONG* >( &m_vers1 ), 0, 0 );
			ra = m_a;

			rb = m_b;

			rc = m_c;

			rd = m_d;
			DWORD vers2 = (DWORD)_InterlockedCompareExchange( reinterpret_cast< volatile LONG* >( &m_vers2 ), 0, 0 );
			if ( vers2 == vers1 )

				break;

		}

	}

};

In this particular task either bandwidth or latency are not the main criteria.I'm concerned about the correctness of the implementation (data consistency) and the absence of synchronization primitives.

I think the topic is closed.Thanks to all!