[USRP-users] UHD and Thread Safety

Andy Walls andy at silverblocksystems.net
Fri Dec 12 09:22:14 EST 2014


The error message is:

"UHD Warning:
    get_time: ValueError: get_nmea(): no GPRMC message found"

which is originating from here:
https://github.com/EttusResearch/uhd/blob/release_003_008_000/host/lib/usrp/gps_ctrl.cpp#L272

But one dropped UDP packet is enough to account for this error, so I'm
not worried about it.  Time marches on, and I get the next $GPRMC the
next second.

I only mentioned it as a symptom that may have been related to thread
safety.  Since it happened so rarely, I thought it may have been
indicative of a race.

After reading Balint's analysis and looking at what I'm doing, I don't
have "thread safety" problems.

Regards,
Andy

On Thu, 2014-12-11 at 19:28 -0500, Andy Walls wrote:
> 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. 
> 
> -Andy
> 
> 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 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
>                 
>         
>         






More information about the USRP-users mailing list