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 <jsem...@gmx.de>:
> 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?
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
