🚀 go-pugleaf

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message 
news:h21mt21bg7maqp25d2lqkr9b1iet0eu3g6@4ax.com...
> "Lesley Anne" <mspfila (dash) brl (at) yahoo (dot) com> wrote:
>
> I'm a bit late, so I'll just throw out some comments
>
> >       pLockSendString->Acquire();
> >       pLockAssocID->Acquire();
>
> You are releasing in the wrong order.
> When using multiple locks, always (in all segments or your program)
> lock them in the same order, and always release in the exact opposite
> order.  This reduces the dreaded Deadlock.

OK, I'll fix that.  Thanks.


> >          pLockSendString->Release();
> >          pLockAssocID->Release();
>
> And then, it looks like you are always using Both locks, never a
> single one, which makes one wonder why you need 2? A single lock
> between the sender (VCL) and the receiver (thread) should suffice.

We used separate locks for each variable we were setting because this Send 
function needed to pass both variables, but the Disconnect function just 
needed to pass the AssociationID.  (There's also a Connect function that 
uses a third TCriticalSection to lock both DestinationAddress and 
DestinationPort variables.)  I just showed the Send in my first post because 
I thought including all three confused the issue more than it clarified it.


> One way out is a simple sentinal.
>
> VCL:
> static volatile bool DataFull = false;
>
> while( DataFull ){ ProcessMessages() }
> SetData()
> DataFull = true
> ThreadSend( DataFull )
>
> ThreadSend( bool & DataFull ):
> ProcessData()
> DataFull = false
>
> VCL can cycle through, but will get stuck until Thread has finished.

I like that this version allows other processing to go on while it's 
waiting, but if that ProcessMessages() picks up another Send function, it 
could be processed before the earlier one.  I'm not sure yet whether we're 
going to care about the order of our messages (in most of our applications 
we don't), but it would be something to keep in mind in case we end up 
copying this into an application where we do care about message order. 
(Even if we don't care about the order of sent messages, if that 
ProcessMessages picked up a Disconnect function, having Send and then 
Disconnect turned into Disconnect and then Send could cause an error.)


> >  (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()
>
> (There is probably some TEvent that makes that easier)

This looks like the safer way to do it, so long as the wait doesn't get long 
enough to hurt performance.  Since this is the first app we're working on 
using the SCTP library, I don't know whether it can lock out the SCTP thread 
for long intervals or not.  (I'm hoping it doesn't anyway.)  We'll probably 
try this (or perhaps its TEvent equivalent) and then do some performance 
testing.

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?)