Re: [Discuss-gnuradio] Thread Safety

[Eric Blossom]

On Mon, Feb 28, 2005 at 12:14:55AM -0500, Krzysztof Kamieniecki wrote:
> The two projects that I am working on right now require some repeated 
> manipulation of various blocks in the flow graph while data is being 
> processed. I would prefer not to have to stop the flow graph to change 
> values. I have some ideas about how to do this but I was wondering if there 
> is a preferred light-weight method.
> -- 
> Krzysztof Kamieniecki
> callsign:KB1KLB
> mailto:address@hidden

Hi Krys,

There are a couple of techniques that should work.  One of them works
now, the other is a bit down the line.

The one that works now is based on this observation:

  There will never be more than a single thread executing the work
  method for a given instance at any time.

Depending on what kind of a parameter you're trying to change, it may
work just to have the set_foo method set a value and a flag that is
checked at the top of the work method.  To have it be rock solid, you
should probably use a mutex to protect the set/get.  See
omnithread.h and use omni_mutex to create one.  See also
omni_mutex_lock for a handy helper.  Under 2.6 (NPTL) the non-blocking
path through a mutex is really quite fast.  It's all in user space.

The second way is currently under development.  This is a message
based interface that uses thread safe message queues and messages.
You would just send a message to your block with the relevant
arguments (change parameter X to Y).  The message would then be
dispatched and acted on in a thread safe manner.  The idea is that the
queues and message ought to able to be used from C++ and python, and
if used from C++ don't incur any python overhead.  I envision adding a
gr_msg_queue to each block, as well as a message receiver method.  The
scheduler would dequeue messages and call the message receiver method
on the block's behalf in a way the was consistent with ensuring
thread-safety.

Eric