How do I ensure that my thread is ready before my main thread continues ?

abiemann

I'm currently experiencing a race condition: my data-receive thread isn't ready by the time it's supposed to receive data

                //create a thread to receive responses from the server
                Thread clientThread = new Thread(new ParameterizedThreadStart(ProcessServerResponse));
                clientThread.Start(RDclient);

                //log activity to client window
                logText("Connected to Server");

                //initiate password syncronization - ProcessServerResponse() should be up and running by now
                //TODO eliminate race condition
                String clientRequest = "SYNC|" + strClientPassword;
                Byte\[\] sendBytes = Encoding.ASCII.GetBytes(clientRequest);
                tcpClientStream.Write(sendBytes, 0, sendBytes.Length);
                tcpClientStream.Flush();

how do I ensure that my ProcessServerResponse() thread is at the .Read() before my main thread sends .Write ?

    private void ProcessServerResponse(object client)
    {
        TcpClient \_RDclient = (TcpClient)client;
        NetworkStream tcpClientStream = \_RDclient.GetStream();
        String strTemp;

        //data array to receive data
        byte\[\] message = new byte\[Properties.Settings.Default.iReceiveBufferSize\];
        int iBytesReceivedCount;

        while (true)
        {
            iBytesReceivedCount = 0;

            try
            {
                //blocks thread until server receives a message
                iBytesReceivedCount = tcpClientStream.Read(message, 0, message.Length);
            }

Luc Pattyn

Have a look at Thread.Join() :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Alan N

Hi, In very general terms the writing thread should wait for a ready signal from the reading thread.

void Initialise() {
  using (ManualResetEvent mre = new ManualResetEvent(false)) {
    Thread t = new Thread(ThreadProc);
    t.Start(mre);
    // continue preparing the writer
    ...
    // wait until reader thread is ready
    mre.WaitOne();
  }
}

void ThreadProc(Object mre) {
  ...
  ((ManualResetEvent)mre).Set();
  ...
  ...
}

The reader thread should signal as soon as it can and the writer should delay waiting until it is ready to write. That way the actual wait period will be minimised. Alan.

David Skelly

What is the advantage of using a ManualResetEvent over an EventWaitHandle? I always use an ewh in these situations. I don't really understand the difference between these two classes and why you would use one rather than the other.

Nicholas Butler

ManualResetEvent and AutoResetEvent are both derived from EventWaitHandle. All they do is set the correct EventResetMode in their constructors. Apart from that, they are identical. Nick

---------------------------------- Be excellent to each other :)

Alan N

Hi David, I doubt that there is any reason to choose one over the other and assume that the Manual and AutoResetEvent derivations are just conveniences that give clarification of intent and self documentation of code. The member documentation shows that none of the EventWaitHandle properties or methods are overridden and only the constructor is new. When moving over from win32 to .NET programming the extent of the libraries was daunting and for me the sight of any familiar name was welcome. I saw ManualResetEvent, thought I know what that does, and stuck with it! Alan.

David Skelly

Alan N wrote:

Manual and AutoResetEvent derivations are just conveniences that give clarification of intent and self documentation of code.

Yes, I can see this. Using ManualResetEvent makes it immediately clear that it relies on something elsewhere in the code manually resetting it (I can guess that from the cunning name they chose for this class). Well, today I have learned something new. Thanks, all.

abiemann

that works great =) thanks, Alan N