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.