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

[Johannes Schmitz]

Hi Johnathan,
can you give me some hint how to use the mutex? Why is it not possible
just to use lock and unlock?

Regards,
Johannes

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