[Top][All Lists]

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

Re: [Discuss-gnuradio] c++ probe block concurrency, locking necessary?

From: Johnathan Corgan
Subject: Re: [Discuss-gnuradio] c++ probe block concurrency, locking necessary?
Date: Fri, 8 Jul 2011 08:46:24 -0700

On Fri, Jul 8, 2011 at 05:45, Johannes Schmitz <address@hidden> wrote:
I am implementing a probe block that stores several values to a member
struct so they can be read from pyhton via accessor method
(get_probe_values() const {return probe_struct;}).
Now my question is: Is it necessary to use some kind of thread locking
mechanism to prevent gnuradio from changing one of the values until
the accessor method can return the whole struct to python?
I am affraid of getting probe values from different "cycles" that
don't belong together.
In other words is it possible that the work() method and
get_probe_values() will be called at the same time and I get some
concurrency problem?

Yes, this is not only possible but likely to happen.  You will need to acquire a mutex in your work function just prior to updating the probe data, and release it afterward.  The accessor function also needs to do the same, copy the probe data locally, then release the mutex.  The gruel library in GNU Radio is has a gruel::mutex for this purpose.  It's really a typedef for boost::mutex, so you can also use that directly.


reply via email to

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