I am experience a problem which I really want to understand.
I have a multithreading application on a FEZ Cerberus. It’s has a two serial reader threads, a keypad input thread and a thread for processing a queue with items to send using the Cellular Radio module. Last but not least a Gadgeteer.Timer with an interval of 1000ms is used to perform some tasks (i.e. updating the text on the character display module, adding data to the queue on particular times, etc…) The ProgramStarted is not blocking.
Everything is working correct for weeks/months now. To finalize the product, I do some tests and stressing the device. One thing I changed starting a TCP/UDP connection time-out, giving the Cellular Radio Module the time to return ‘CONNECT FAIL’ instead of timing-out the serial command by myself. Purpose of this is to generate more specific errors (i.e., ‘Start TCP/UDP connection failed’ instead of ‘Serial command time-out’). I know I can achieve this on different ways, but I do like to understand the behavior I am currently facing.
This is what happens:
The queue processing thread (so, not the mainthread and not the GT.Timer thread) is issuing the command to start a TCP/UDP connection. It’s sending the appropriate command to the module and then waiting for the result for max X seconds. This waiting for the result is achieved by using a while loop which inside is using a Thread.Sleep(100) and so check each 100 ms for a result until a time-out for waiting for the result occur.
The command result time-out is standard 10 seconds and for starting a TCP/UDP connection 30 seconds. I have expand this time-out for the latter to 80 seconds to give the Cellular Radio module the chance to return CONNECT FAIL. Okay, 80 seconds is long, but apart from the discussion whether the time-out is too long, I am facing the problem that after waiting for the command result for more than about 20 or 30 seconds, the device is freezing and the GT.Timer is no longer working. The queue processing thread is still working and after the time-out is elapsed, the GT.Timer is going to work again.
Using VS I can see a few ‘Failed allocation for xx, xx’ after the queue processing thread is released. This triggers me to conclude that the garbage collector is not able to cleanup the used memory during the hold-up of the processing queue and so causing the other threads to working incorrectly. I might be totally wrong, but I do want to know what’s going on
Can someone explain this described behavior and maybe have a solution for it? It has nothing to do with locking since even an empty timer which only do a Debug.Print stops working. The serial reader thread of the Cellular Radio module remains working though.
Thanks in advance for your reply!