G
Guest
We have an odd problem with an unexpected 500ms delay that seems like it may
be coming from within the .NET framework. We are using VS2005, and the
problem exhibits using both Beta1 and Beta2.
I have developed a simplified console application which demonstrates the
problem for anyone interested. Essentially, the application opens a serial
port (using System.IO.Ports.SerialPort) , and sets up a chain of threads from
the thread pool (using BeginInvoke from a delegate) which each wait on an
AutoResetEvent, then send a command to the serial port, wait for a response,
and then signal the next thread to proceed.
Although it generally works, we find that there is exactly a 500ms delay
before each thread is started. Since the response from the serial port also
arrives as a callback from the thread pool, and only executes after all the
other threads have started, if we run with, for example, 10 threads, it is 5
seconds before we get the callback for the characters received, even though
on an RS-232 line monitor we can see that the characters arrive to the PC
immediately. After the first one, the other responses arrive in a timely
manner.
It is not a CPU utilization issue; the delay is exactly 500ms per thread,
and the CPU is at 0% during that time.
I have a simple console application which demonstrates the problem, which
can be compiled for either Beta 1 or Beta 2 (since the serial port API
changed a little between them). It requires a null modem RS-232 cable to
connect two PC's, each running this sample application.
It sure appears to us to be a .NET framework issue, and it is impacting our
ability to release our product. Any insight would be appreciated.
be coming from within the .NET framework. We are using VS2005, and the
problem exhibits using both Beta1 and Beta2.
I have developed a simplified console application which demonstrates the
problem for anyone interested. Essentially, the application opens a serial
port (using System.IO.Ports.SerialPort) , and sets up a chain of threads from
the thread pool (using BeginInvoke from a delegate) which each wait on an
AutoResetEvent, then send a command to the serial port, wait for a response,
and then signal the next thread to proceed.
Although it generally works, we find that there is exactly a 500ms delay
before each thread is started. Since the response from the serial port also
arrives as a callback from the thread pool, and only executes after all the
other threads have started, if we run with, for example, 10 threads, it is 5
seconds before we get the callback for the characters received, even though
on an RS-232 line monitor we can see that the characters arrive to the PC
immediately. After the first one, the other responses arrive in a timely
manner.
It is not a CPU utilization issue; the delay is exactly 500ms per thread,
and the CPU is at 0% during that time.
I have a simple console application which demonstrates the problem, which
can be compiled for either Beta 1 or Beta 2 (since the serial port API
changed a little between them). It requires a null modem RS-232 cable to
connect two PC's, each running this sample application.
It sure appears to us to be a .NET framework issue, and it is impacting our
ability to release our product. Any insight would be appreciated.