[USRP-users] UHD and Thread Safety
balint.seeber at ettus.com
Thu Dec 11 19:06:36 EST 2014
Apologies - I advised Ben a little too soon before double checking all the
The following applies to third generation radios (B2x0, E310 & X3x0) -
these use radio_ctrl_core_3000 so send control/configuration packets to the
radios on these devices:
Settings bus registers are updated in/results are read back from each radio
core in the FPGA by performing a peek or poke. peek32, peek64 and poke32
are provided by radio_ctrl_core_3000, and each of these individual
operations are thread safe (there is a mutex in each function). These calls
are also blocking, so they will wait for an ACK to come back from the core
(this contains the result in the case of a peek). As a side note, if you
have a transport failure, then you'll see the standard 'timed out waiting
for ACK' exception thrown from radio_ctrl_core_3000.
Now to those specific functions:
- get_time_now (from time_core_3000): a single peek64, so it *is* thread
safe (you can call this from any thread, and probably will in complex
applications that might have a main app thread, a thread for RX, another
for TX, and perhaps something to handle TX asynchronous messages and/or
other device status like PLL/ref lock, GPS, etc). Same applies to
set_time_now/set_time_next_pps are implemented as three poke32 calls,
and those calls are *not* in a mutex, so you wouldn't want to call them
from different threads - but then again you probably would never do this
anyway, since it doesn't make sense to do so (you generally would call one
of the two once during device init).
- Anything to do with the GPS is *not* thread safe. You should
synchronise calls to the sensors API only if you're doing this from
different threads. If you know you'll only be doing this from one thread
*only*, then it's *not* necessary to synchronise (i.e. you don't need to
synchronise *all* accesses to *any* function in one multi_usrp instance).
Moreover, since much of multi_user actually sets/gets items on the device
instance's property tree, it's worth noting that manipulating the
*structure* of the property is thread safe, but actually setting/getting
node values (i.e. triggering publishers/subscribers/coercers) is *not*
thread safe (i.e. thread safety relies on the underlying implementation(s)
that get(s) called).
Andy, when you say 'complain' you mean UHD output a log message, but didn't
throw an exception? I imagine this had to do with the last received RMC not
being considered 'fresh' any more, and perhaps a new one has not arrived
yet in the buffer due to delays on the transport. You might want to match
the message up with uhd/host/lib/usrp/gps_ctrl.cpp.
Hope that helps and doesn't cause any race conditions for you!
On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users <
usrp-users at lists.ettus.com> wrote:
> FWIW, I use a custom GNURadio block for closed loop monitoring of GPSDO
> and USRP time between the host and the USRP. Polling every two seconds, 25
> msec after the PPS, I occasionally see UHD gripe about the GPRMC message
> not being available. I never bothered to track down the cause.
> On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>> Okay, we are debating the safety of polling for sensor data here within
>> the R&D team. At this point, we have flip-flopped several times.
>> Balint will respond shortly with our final guidance =)
>> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <ben.hilburn at ettus.com>
>>> Actually, what I just said is wrong, because calling those functions
>>> will result in packets being sent from the device.
>>> So, no. Nothing is thread safe, and even polling for sensor data could
>>> cause issues.
>>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <ben.hilburn at ettus.com>
>>>> Hi Nathan -
>>>> Generally, any UHD function that doesn't involve streaming is *not *thread-safe.
>>>> So if you called "get_time_now" from two separate threads at the same time,
>>>> that is *not* a thread-safe operation.
>>>> If all you are doing is polling sensors from a thread that is different
>>>> from the thread in which you started streaming, you should be OK. But, it
>>>> is not technically thread safe.
>>>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>>>> usrp-users at lists.ettus.com> wrote:
>>>>> I’ve been assuming that calls to UHD functions that don’t change
>>>>> settings on the USRP are generally thread safe and can be called from
>>>>> another thread even while a capture is ongoing. Is this an accurate
>>>>> assumption? The functions I’m calling are get_mboard_sensor() (for GPS
>>>>> information and ref_locked) and get_time_now(). Thanks.
>>>>> -Nathan Perelman
>>>>> USRP-users mailing list
>>>>> USRP-users at lists.ettus.com
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users