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

[Martin Braun]

lock() and unlock() affect the running of the flow graph; you don't want
to interrupt the sample stream.

Find an example of a mutex:
% grep "gruel::mutex" * # Grep is your friend!
gr_histo_sink_f.h:  gruel::mutex d_mutex;

See that file (and the .cc) as a reference.
Mutexing for this case is very simple.

Have fun,
MB

On Mon, Jul 11, 2011 at 12:57:31PM +0200, Johannes Schmitz wrote:
> 
> 
> 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?
> >>
> >
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

pgp2aEF6rE7AE.pgp
Description: PGP signature