Main Site Documentation

A blocking thread is causing the mainthread / GT.Timer to freeze on FEZ Cerberus



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 :slight_smile:

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!



Can you show your code?


Thanks for your reply. I have already solved this problem.

Unfortunately it was a locking issue, as always with threads :slight_smile:

I was using the GT.Timer in another controller which periodically refreshes the signal quality which I display on the screen. I use a lock around the communication with the Cellular radio module so the pending commands are not interfere with each other. Since the start TCP/UDP command was still pending the refresh signal quality call could not be performed and so the GT.Timer.Tick method call was blocked causing the other GT.Timer.Tick calls to be blocked too.

As I have seen in the call stack the GT.Timer calls are called from the main thread causing both the timers and garbage collector to be not executed.
I have learned again: prevent blocking in the GT.Timer.Ticked event handlers.

Thanks for your effort to read my story though!


Good to hear you have it sorted out.