Re: [Discuss-gnuradio] Thread Safety

[Eric Blossom]

On Mon, Feb 28, 2005 at 02:09:02AM -0500, Krzysztof Kamieniecki wrote:
> 
> Eric Blossom wrote:
> >
> I was thinking about something slightly more complicated, with a set of 
> shadow data members that would be protected by the mutex, and copied to the 
> normal data members at the top of the work method when the flag is 
> triggered. That way the mutex would only be used if the flag is set. 
> Something like this.

This all looks good.

> 
> I had noticed the development in CVS. Having a gr_msg_queue in each block 
> may cause some problems for me down the line unless there is a way to 
> guarantee that the messages are processed in a specific order, but it's 
> something that I could work around.

> Do or could the messages have a timestamp indicating when they should be 
> performed?

I was thinking along the line of a timer that sends "Timer Fired"
messages to whoever you want when you want.  If it seems more useful
to queue up an arbitrary message for delivery in the future, we could
implement that.

I thought that the message queue per block would simplify matters when
dispatching messages for the block.  I figured on processing pending
messages for each block just before the scheduler called forecast.
This would ensure that for each run through the scheduler loop, all
messages pending for a given block were processed just before calling
forecast/work.  Does this sound like it will take care of your needs?

You may have noticed that gr_msg_queue is derived from gr_msg_handler.
I figured this would give us the flexibility to write arbitrary message
handling code that runs at message send time if we needed it.  This
would correspond to Click's "push" based processing model.  

I suspect that for most cases the message queue is the right answer
(at least for blocks), since it gives a simple way to hide the
concurrency issues from the block.  We could certainly do both the per
block message queue and the "please send this message at Time X"
message queue.  I also figured on supporting message send on "select"
events too.

Comments?

Eric