c# multithreading problem

[think2]

I'm having a problem with a C# program built with Visual Studio 2015 running on Windows 10. The program sends a message (a poll) on a serial port at 38400 baud to a device that replies with its status within 15 milliseconds. I have a timer to check for no response
timerAckTimeOut = new System.Timers.Timer();

I have two problems. With the ackTimeout interval set to 20 milliseconds and a poll rate of one poll every 10 milliseconds, I occasionally get spurious ack timeouts. Secondly, in the code below, the variable seq_ok is occasionally getting set to false yet when I display the values of b1 & b2 (via a queue) they are always the same so why is seq_ok getting set to false?

To take the serial comms out of the equation I replaced the serial port stuff with a timer interrupt that "pretends" a message has been received if the ack wait flag is set. With a poll rate of 10 milliseconds, a pretend receive timer rate of 4 milliseconds and an ack timeout of 20 milliseconds, I get quite a few ack timeouts. How accurate are System.Timers.Timer ?

       private void ProcessReceivedMessage(byte[] buf, int numbytes)
       {
           byte[] local_buf = new byte[numbytes];
           // copy the message because buf can be overwritten before this function finishes
           // processing it
           Buffer.BlockCopy(buf, 0, local_buf, 0, numbytes);

           byte b1 = (byte)(local_buf[2] & 0x3f);
           byte b2 = QBusSequenceNumber;
           bool seq_ok = (b1 == b2);
           lock(timerAckTimeOut)
           {
               if (WaitingForAck)
               {
                   timerAckTimeOut.Stop();
                   WaitingForAck = false;
               }
           }
           
           // qbus_AckRecv will call SendMessagesIfReady
           if(AckRecv != null)
               AckRecv(this, EventArgs.Empty);

           if (seq_ok)
           {
               // whatever...
           }
           else
           {
               add_to_status_display_queue(String.Format("Seq #{0:d}: {0:d}", b1, b2));
           }
       }

 

[Apathetic]

I would have thought 15 ms resolution (64 ticks per second) would be fine, but it's been a long time since I've dealt with this stuff. Have you looked at the high resolution timer?

Dave

 

[Merad]

Are you calling Thread.Sleep() while you wait for the timer to be ready? IIRC, by default Windows allocates programs a time slice of 15-20ms. If you call sleep (even Thread.Sleep(1)), you give up the rest of your time slice and that's probably enough for you to miss the response. I think your main alternatives are going to be either busy waiting or using waitable timers, which claim a resolution of 100ns.

 

[you2]

Does window C# support cond-wait pthread primitives ? I believe that is the optimal solution.

 

[Schmide]

Should you be locking a mutex in a message callback? You could be blocking future messages while waiting for the lock. I'm not saying never lock things in a callback, but be sure they aren't long time blocks. 15-20ms in a message queue is computer time eternity.

 

[think2]

Thanks for all the replies. I finally found out that I had a mistake in the following piece of code and it is printing out b1 twice instead of b1 then b2. I'm new to C# and unfamiliar with the C# format function. A compiler warning would be nice here.

 add_to_status_display_queue(String.Format("Seq #{0:d}: {0:d}", b1, b2));

.
So I have a synchronization problem to fix. I can live with the 15 ms timer resolution once I get my code fixed I think.