[Top][All Lists]

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

Re: [Discuss-gnuradio] Thread Safety

From: Krzysztof Kamieniecki
Subject: Re: [Discuss-gnuradio] Thread Safety
Date: Tue, 01 Mar 2005 01:01:33 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

Eric Blossom wrote:
> On Mon, Feb 28, 2005 at 02:09:02AM -0500, Krzysztof Kamieniecki wrote:
>>Do or could the messages have a timestamp indicating when they should be
> 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 think this will have to take into account timestamped sample buffers you 
mentioned before. For
instance a waveform/protocol may require adjusting gains in the TX/RX path 
between data packets.

> 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

This sounds good. One additional feature that would be useful is some way to 
specify that a batch of
messages to multiple blocks should be queued in an "atomic" manner, so all of 
the messages get
processed during the same pre-forecast time frame.

So for a network analyzer you can send a message to the signal source block and 
another to the
downconverter block to switch frequencies at the same time and maintain their 
phase relationship.

Krzysztof Kamieniecki

reply via email to

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