[USRP-users] UHD and Thread Safety

Perelman, Nathan nperelman at LGSInnovations.com
Fri Dec 12 13:02:54 EST 2014


Thanks for the details. Sounds like everything I’m doing should be ok, although I’m doing it with N2x0s. Are there any significant differences for the N2x0?

-Nathan

 

From: Balint Seeber [mailto:balint.seeber at ettus.com] 
Sent: Thursday, December 11, 2014 7:07 PM
To: Andy Walls
Cc: Ben Hilburn; Ben Hilburn via USRP-users; Perelman, Nathan
Subject: Re: [USRP-users] UHD and Thread Safety

 

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/20141212/36c64a49/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4327 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141212/36c64a49/attachment.p7s>


More information about the USRP-users mailing list