[USRP-users] UHD and Thread Safety

Balint Seeber balint.seeber at ettus.com
Thu Dec 11 19:06:36 EST 2014


Hi all,

Apologies - I advised Ben a little too soon before double checking all the
code paths.

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
   '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 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!

Kind regards,
Balint

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.
>
> -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 within
>> 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 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.
>>>
>>> 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 *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.
>>>>
>>>> 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 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
>>>>> 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
>>
>>
> _______________________________________________
> 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/8a91f293/attachment-0002.html>


More information about the USRP-users mailing list