🚀 go-pugleaf

(As the subject line suggests, this is actually a threading question rather 
than a socket question, but threading didn't seem to fit the topics for any 
of the boards here.  Socket communication is why I needed the threads in the 
first place though, so this was as close as I could find to a relevant place 
to ask this.)

I've worked occasionally with multi-threaded apps before, but in those 
instances the main VCL thread would spawn temporary helper threads which 
would do one thing and then finish.  I would use Synchronize() to pass info 
from the helper threads back to the VCL thread, but the only info passed 
from the VCL thread to the helper threads would be passed as parameters to 
the thread class's constructor.

Now I've got a different situation, where I need to keep a secondary thread 
active throughout the life of an application, and be able to repeatedly pass 
information to it from the main VCL thread.  I'm trying to figure out how to 
do that in a thread-safe manner.  Perhaps I should start with showing what I 
have so far, and then explain my concerns about it.

Declared globally in the main form's unit, and extern in the thread class's 
unit, I have:

   String       VCLToSctpMessage;
   unsigned int VCLToSctpAssoc;
   TCriticalSection *pLockSendString;
   TCriticalSection *pLockAssocID;

Within one of the functions on my main form, I have:

       pLockSendString->Acquire();
       pLockAssocID->Acquire();
       try {
          VCLToSctpMessage = String(buffer);
          VCLToSctpAssoc = associationID[Site];
       }
       __finally {
          pLockSendString->Release();
          pLockAssocID->Release();
       }
       if (sctpThread)
          sctpThread->Send();

And in my SCTP thread (a TThread descendant) the Send function looks like 
this:

// -----------------------------------------------
void TsctpThread::Send(void)
{
   unsigned char Message[4096];
   unsigned int associationID;
   int Length;

   pLockSendString->Acquire();
   pLockAssocID->Acquire();
   try {
      Length = VCLToSctpMessage.Length();
      strcpy(Message, VCLToSctpMessage.c_str());
      associationID = VCLToSctpAssoc;
   }
   __finally {
      pLockSendString->Release();
      pLockAssocID->Release();
   }

   sctp_send(associationID, 0, Message, Length,
             SCTP_GENERIC_PAYLOAD_PROTOCOL_ID,
             SCTP_USE_PRIMARY, SCTP_NO_CONTEXT,
             SCTP_INFINITE_LIFETIME,
             SCTP_ORDERED_DELIVERY,
             SCTP_BUNDLING_DISABLED);
}
// -----------------------------------------------

OK, now I'm pretty sure that the TCriticalSections will make it thread-safe 
in terms of not having both threads access the variables at the same time, 
but I'm not sure whether I can count on the sctpThread reading in the values 
of the variables before another function in the main VCL thread (or another 
instance of the same function) changes the variables to something else.

If the first section of code above (the part in my main form) were to fire 
off twice in rapid succession, once setting VCLToSctpMessage to "hello" and 
then setting it to "goodbye", could I count on the Send function in my 
sctpThread picking up "hello" for the first instance and "goodbye" for the 
second, or could it wind up seeing "goodbye" twice?

If my concern is valid, and it could show up as "goodbye" twice, then how do 
I fix it?  I got stuck with repeatedly using global variables because I 
didn't think the scope rules would allow me to send local variables to the 
thread, but I don't want to allow re-use of those global variables until the 
thread has seen their current values.  (Or would it be OK to pass local 
variables to the thread?  How would that work?)