Official bladeRF forum

Simon,

Sounds like a good plan. I'll touch base soon.

Hi Simon,

The thread-safety changes are up in master and seem to have been holding up well; I've been beating the changes up with some tests and a few other SDR programs. The Doxygen pages have been updated accordingly.

If what you were seeing was the result of calling bladeRF "control" calls from multiple threads, this should help. As I mentioned earlier, it was previously possible to concurrently to do things like change frequency/bandwidth while a stream was running, if one was careful to keep control calls in one thread, and data stream calls in another (and be sure not to cross the streams!).

If you run CMake with -DENABLE_LOCK_CHECKS (or from the GUI, check the ENABLE_LOCK_CHECKS checkbox), all lock acquisition functions be wrapped with an assert() for success, quickly causing any deadlock scenarios to grind to a halt at the line they occur.

The libbladeRF_test_ctrl program now contains a "threads" test, which can be run on its own via: Not that these test take a while to run. Without the "-t" argument, all tests shown by libbladeRF_test_ctrl -L will be run. If you want to run tests with the XB-200 attached and in use, there's a --xb200 argument.

I'll be AFK this weekend while at DEFCON, but some other folks on here might be able to offer assistance. Just wanted to post an update so you can take a look at your leisure -- I know you're working on lots of other cool stuff in the meantime.

Have a good one!
Jon