[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Message Queue Thread Safety

From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Message Queue Thread Safety
Date: Thu, 23 Feb 2012 11:47:47 -0500

On Tue, Feb 21, 2012 at 10:48 AM, Ryan Pape <address@hidden> wrote:

On Mon, Feb 20, 2012 at 10:28 AM, Tom Rondeau <address@hidden> wrote:
On Sun, Feb 19, 2012 at 6:29 PM, Ryan Pape <address@hidden> wrote:
I have an application with some nasty race conditions I am trying to pin-point.

The application starts with a 256 channel filterbank. Approx 45 outputs are connected to files, a handful to other blocks ending with a custom block that puts messages in a GR message queue.

Occasionally, and randomly, one of the chains with my custom block appears to stall for an extended time and puts no messages into the queue.  It appears it may restart at a random later time, and in every case I have observed restarting the application fixes the problem immediately. At the same time, another chain continues to send messages as I would expect.

Is having two or more producers and one consumer on one GR message queue across multiple threads a bad idea?  I'm not employing any additional locking on the queue, due to wishful thinking and ignorance.  I could move to a one consumer for each producer model and it would not significantly change my application.


So the custom sinks are doing an insert_tail onto the msg_queue and the other thread is doing a delete_head() to get the messages out?

Are they all going into the same queue, or does each sink have it's own queue to send messages to?

The insert_tail and delete_head both lock a mutex when called, so they are (or should be) thread safe. I'm trying to get a clearer picture of your setup to see what else could be happening.

Tom, thank you for the reply. 
You are correct with insert_tail from custom sink (2-5 in the application, 1-10msgs/second each at peak) into ONE queue. A separate thread continuously looping and delete_head()


There should be nothing inherently wrong with this approach.

Is there any other way to monitor the producer blocks to make sure they are actually getting data to send to the queue? Some output to stdout when they are active in any way?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]