Hey guys,
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.
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.
I am really kind of a beginner when it comes to this mutex stuff.
Since we don’t have the newest gnuradio version from git running here
it seems I need to use something called mld_mutex instead of gruel.
I found this via google in usrp/host/lib/fusb_darwin but it is not
working. I couldn’t find out which header to include.
My idea was to do something like this:
d_metric is a struct
