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

[Johannes Schmitz]

I changed my code to use boost::mutex now. Therefore I included
#include <boost/thread.hpp>

Then I did something like this, which made my program go into a deadlock :(

in header:
boost::mutex d_metric_mutex;

in .cc
d_metric_mutex.lock();
d_metric.x = 1
d_metric.y = 2
d_metric_mutex.unlock();

and accessor:

metric get_metric ()
{
    d_metric_mutex.lock();
    return d_metric;
    d_metric_mutex.unlock();
}

2011/7/8 Johannes Schmitz <address@hidden>:
> 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?
>