🚀 go-pugleaf

"Lesley Anne" <mspfila (dash) brl (at) yahoo (dot) com> wrote:

>> >  (Or would it be OK to pass local
>> > variables to the thread?  How would that work?)
>>
>> You would need to wait for the thread to copy them.
>>
>> VCL:
>> SetData();
>> ThreadSend( LocalData )
>> WaitForSingleObject( hDataAquiredEvent, 10000 );
>> Thread:
>> CopyData();
>> Signal( hDataAquiredEvent );
>> ProcessData()
>
>Does this waiting for an event signaling that the thread has finished 
>reading its input parameters take care of making it thread-safe?  (i.e. Does 
>it allow us to just pass in parameters without needing the critical 
>section?)

Yes. The thread has copied the application's local data into it's own
local data before signaling, so the application data is free to
disappear.

I see that you are also concerned about the Thread falling behing the
application, and getting messages out of order. One way out is to add
a ring buffer.
The application stuffs data into the head of the ring, then tells the
thread that new data is available. (Once again, the data is now in an
escrow buffer, so the application data can change or "go away".)
The thread takes data off the tail of the ring, and sends it.
It is possable to construct a ring buffer so that no locking is
required. Only reason to use locks would be if you have more than one
writter (application) thread, or if you have more than one thread
reading from it.

When the ring fills, the application stalls until the sender can free
up a spot.

 VCL:
	while( IsRingBufferFull() ) Sleep(0);	// wait for an opening
	StuffDataIntoRingBuffer();
	NextRingBufferHead();	// fullfills RingBufferHasData()
	Signal( hSendDataAvailableEvent );	// wake up

Thread:
	while( ! Terminated )
	{
		WaitForSingleObject( hSendDataAvailableEvent, 1000 );
		while( RingBufferHasData() )
		{
			Data = ReadRingBufferData();
			NextRingBufferTail();  // unblocks VCL while()
			Send( Data );
		};
	};

To bring this back on-topic....
I don't know if there is an STL ring buffer, but you might want to
investigate using auto-pointers to hold your messages, so the buffer
would be holding pointers to messages instead of the actual messages.
Since message may be of variable length, it might be hard to design a
ring buffer of sufficient size to hold raw messages.

If you find that your ring fills up and stays full, even if you make
it quite large, then you might want to look into boosting the thread
priority (or adding another socket if the application could use it)