[USRP-users] UHD and Thread Safety

Andy Walls andy at silverblocksystems.net
Thu Dec 11 19:28:43 EST 2014

Hi Balint,

I force a UHD NMEA cache refresh by fetching gps_time 26 msec after the PPS.  See the code segment here: http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-August/010469.html .  I dont think it is a freshness issue.

I'll reproduce the error tomorrow at work to hunt down the message. It happens less than once per hour as an estimate.  It has no ill effects for me, so meh.  


On December 11, 2014 7:06:36 PM EST, Balint Seeber <balint.seeber at ettus.com> wrote:
>Hi all,
>Apologies - I advised Ben a little too soon before double checking all
>code paths.
>The following applies to third generation radios (B2x0, E310 & X3x0) -
>these use radio_ctrl_core_3000 so send control/configuration packets to
>radios on these devices:
>Settings bus registers are updated in/results are read back from each
>core in the FPGA by performing a peek or poke. peek32, peek64 and
>are provided by radio_ctrl_core_3000, and each of these individual
>operations are thread safe (there is a mutex in each function). These
>are also blocking, so they will wait for an ACK to come back from the
>(this contains the result in the case of a peek). As a side note, if
>have a transport failure, then you'll see the standard 'timed out
>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*
>  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,
>for TX, and perhaps something to handle TX asynchronous messages and/or
>   other device status like PLL/ref lock, GPS, etc). Same applies to
>   'get_time_last_pps'.
>  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
>anyway, since it doesn't make sense to do so (you generally would call
>   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
>*only*, then it's *not* necessary to synchronise (i.e. you don't need
>synchronise *all* accesses to *any* function in one multi_usrp
>Moreover, since much of multi_user actually sets/gets items on the
>instance's property tree, it's worth noting that manipulating the
>*structure* of the property is thread safe, but actually
>node values (i.e. triggering publishers/subscribers/coercers) is *not*
>thread safe (i.e. thread safety relies on the underlying
>that get(s) called).
>Andy, when you say 'complain' you mean UHD output a log message, but
>throw an exception? I imagine this had to do with the last received RMC
>being considered 'fresh' any more, and perhaps a new one has not
>yet in the buffer due to delays on the transport. You might want to
>the message up with uhd/host/lib/usrp/gps_ctrl.cpp.
>Hope that helps and doesn't cause any race conditions for you!
>Kind regards,
>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
>> 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
>> not being available. I never bothered to track down the cause.
>> -Andy
>> 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
>>> the R&D team. At this point, we have flip-flopped several times.
>>> Balint will respond shortly with our final guidance =)
>>> Cheers,
>>> Ben
>>> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn
><ben.hilburn at ettus.com>
>>> wrote:
>>>> Actually, what I just said is wrong, because calling those
>>>> will result in packets being sent from the device.
>>>> So, no. Nothing is thread safe, and even polling for sensor data
>>>> cause issues.
>>>> Cheers,
>>>> Ben
>>>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn
><ben.hilburn at ettus.com>
>>>> wrote:
>>>>> Hi Nathan -
>>>>> Generally, any UHD function that doesn't involve streaming is *not
>>>>> 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
>>>>> from the thread in which you started streaming, you should be OK.
>But, it
>>>>> is not technically thread safe.
>>>>> Cheers,
>>>>> Ben
>>>>> 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
>>>>>> another thread even while a capture is ongoing. Is this an
>>>>>> 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
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141211/f62ebae2/attachment-0002.html>

More information about the USRP-users mailing list