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.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:[EMAIL PROTECTED]
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.
//called by external thread i.e. Python
void
freq_set(float value)
{
//lock critical section
Lock lock(d_shadow_crit_sec);//set shadow data d_freq_shadow = value;
//signal flow graph thread d_shadow_flag = true; }
//called by flow_graph thread
void
update_values()
{
//lock critical section
Lock lock(d_shadow_crit_sec);//clear new data flag d_shadow_flag = false;
//read shadow data d_freq = d_freq_shadow; }
int work(...) { if(d_shadow_flag) update_values(); ... }
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
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?
-- Krzysztof Kamieniecki callsign:KB1KLB mailto:[EMAIL PROTECTED]
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
