Why does WriteFile hang?

[PeterSteele]

I have a program set up with two threads, one intended to read incoming data from the 631 and another that writes data to the 631. The read thread uses WaitCommEvent so that it sleeps until there is data to read. The write thread uses WriteFile to send packets to the 631 com port. When the first WriteFile is performed, the read thread wakes up as expected and processes the incoming response data that was generated as a result of the WriteFile operation. After it has read the data, it issues another WaitCommEvent and then goes back to sleep. So far so good.

The problem occurs when the write thread then issues its next WriteFile operation. Instead of returning immediately from the call as expected, it just hangs, and the read thread that is sleeping on the call to WaitCommEvent continues to sleep. The only way I can wake these threads up is by pressing a button on the 631 keypad. When I do this the WriteFile immediately completes and the WaitCommEvent call wakes up. The read thread then proceeds to read incoming data for both the WriteFile that had hung as well as the event data generated by the key press.

So why does WriteFile hang? The read/write threads work exactly as I intended on the first write attempt but after that the WriteFile operation hangs. Am I missing something obvious?

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

Thank you for your post.

Unfortunately I do not know much about using threads. I'll ask CF Support to look at this post . . . they have some experience with threads.

At least for debugging, you might try setting each thread up to get hit by a timer, say twice a second, and use get comm status, instead of using the WaitCommEvent(). That style would not stall and maybe the results of GetCommStatus() would offer some insight to what is happening.

 

[PeterSteele]

If I eliminate the WaitCommEvent call and instead just have the read thread loop checking for data every second or so, WriteFile does not appear to hang, at least not in my tests. This is what I was trying to avoid though. 99% of the time there will be no data to read and I wanted to use WaitCommEvent so the read thread isn't just wasting CPU cycles. I've used a similar technique in the past for reading data from pipes and it's definitely the preferred approach. Is there a way I could accomplish the same thing in managing the 631?

 

[CF Support]

This does not seem to be a thread problem necessarily, however, it does appear to be a common one when using WaitCommEvent.

A quick google search reveals basically the same thing you're experiencing, in general. The problem has appeared to follow all of M$'s OSs since Win95 or earlier. A few helpful posts are:

http://alumnus.caltech.edu/~dank/overlap.htm

http://www.ntdev.org/archive/ntdev9803/msg0397.html

http://www.codeproject.com/system/serial.asp

In any event, you may try a wrapper for the serial I/O, like this one:

http://codeproject.com/system/cserialport.asp?df=100&forumid=440&exp=0&select=788844

It is at least possible that they have overcome the problem.

Your mileage may vary.