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

[Johannes Schmitz]

Thanks for your answer.

> 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

d_metric_mutex->lock();
d_metric.x = something
d_metric.y = something
d_metric_mutex->unlock();

metric get_metric () const
{
    d_metric_mutex->lock();
    return d_metric;
    d_metric_mutex->unlock();
}

So when I return a struct to python via SWIG, what will happen. Will
there be some copy of it generated?