Re: [Discuss-gnuradio] Clarification of lock() and unlock() in Dynamic Flow-Graph Reconfiguration

[Venkat Vinod]

Hey,

We have tried just about every different combination of start,stop,wait,lock, and unlock possible ....

Whenever we remove the stop() call, we get an error that we do not receive whenever the stop() call is in place. With the stop() call removed, the program gives us the following error at the unlock() statement:

                 terminate called after throwing an instance of 'boost::thread_interrupted'
                 Aborted

This error does not come up if we remove the stop() statement, but the program freezes at the unlock instead. Any clues to solving the boost error or what this actually means?? 

From viewing the version 3.2.2 API documentation
 for the gr_top_block class, there is a note saying that "the lock() and
 unlock() methods should not be called from a flowgraph thread or the 
program will be become deadlocked". In my program the lock() and 
unlock() are being called from the same top_block() which is 
instantiated when the program is started. Could this be the cause of 
freezing once we get to the unlock statement? 

Once again thanks for your help. I was extremely surprised at how quickly you guys responded :)

>

> A couple of things to try:

>Try removing the tb.stop() call, lock will stop the flowgraph anyway.

>You may need to 'disconnect' (essentially undo all the connect calls) the path before recreating it. In the first instance try >the disconnect_all() method, but from memory that had some issues so you could try calling disconnect for each block which was connected.

 

>             else:
>               print "Receiver Mode : USRP to Switch to Receiving Packets "
>               self.tb.stop()

Don't call stop.  Just call lock.

-- 
Venkat Vinod Patcha and Ben Carroll