03-16-2011 03:30 PM
Hello,
I used the NI example for a multi-client TCP server in a program, and I would like to report a bug (I'm not sure if this message is the appropriate place).
A little background on the example:
When new clients connect to the server, a new thread is created/started. Within the new thread, the thread ID is assigned to the data structure for that client (clientInfoPtr->threadId). While this is all going on, the ServerCallback callback is still being called and processing incoming TCP data.
That all said, the problem comes as a race condition can occur if TCP data (for the newly connected client) is received, before the client thread actually assigns the threadId. Here, PostDeferredCallToThread() is called passing in the threadId, and readingData is set to 1, however the threadId is not actually valid yet, so the DeferredReceive callback is never actually executed. Finally, we are left in a state where readingData = 1, and will never be set back to 0 because this is done within DeferredReceive.
I fixed this problem with the following:
I always memset (0) my newly allocated structure when I create it, thus, my threadId is initially 0. So within ServerCallback(), I only set readingData = 1 and call PostDeferredCallToThread() if(threadId != 0). This will prevent the thread from getting into this locked and unrecoverable state, as it will not set readingData to 1 unless the client thread is properly initialized.
Hope this helps someone!!
-Jamie
03-17-2011 04:14 PM
Thanks for the heads up Jamie! I will look into it on my end and likely file a Corrective Action Request (CAR) so we can make a change in the shipping example.
03-18-2011 04:03 PM
Jamie,
The corrective action request for this is CAR# 289838.