Claiming endpoint vs mutex protected access to endpoint

[ratzrattillo]

I am writing a driver for the BladerRF Software Defined Radio device.
Previous to the redesign of nusb, i shared an "nusb::Interface" with different structs that represent individual pieces of hardware - controllable via USB using NIOSII packets. Then, in the method-impls for the structs, i used the individual endpoints to send data to the SDR.
After the redesign, the references to the endpoints must be &mut. Thus, sharing the endpoints between multiple structs is not possible anymore.
@kevinmehall Would you suggest to share the interface like i did before and always claim the endpoint in each method, where data shall be sent via USB?
Or is it better to have those endpoints in a global "UsbBackend" struct behind a Mutex?

I would personally prefer to avoid any locking. I also believe, that nobody should try to concurrently call any routines on an SDR, because these devices are by default meant to be configured and used in a non concurrent fashion.

[kevinmehall]

The Endpoint has internal state tracking pending transfers, so I made it take &mut so that if it is single-owner it doesn't have to pay the cost of synchronization. Typically, it would be owned by a single thread or async task, but if you need to share it you can wrap it in a Mutex. It is not extremely expensive to create an Endpoint, but not intended to be re-created every time you submit a transfer. The big problem with that pattern would be that dropping an Endpoint cancels all of its pending transfers.

If you were using Queue on v0.1 (and you should be for a SDR, to submit multiple transfers to avoid underflow/overflow in gaps between transfers), Queue is effectively now called Endpoint.

For a SDR, I would do something like a Stream struct created when you start transmit or receive that contains the Endpoint, or maybe two separate objects for transmit and receive that may be handled on separate threads. You then use those objects to send or receive samples, and cancel the transfers and release the endpoint when streaming stops. Basically that would be passing the exclusive ownership onto the caller, where they could put it in a Mutex or not depending on their needs. If there are shared endpoints used for controlling the device rather than streaming the sample data, a Mutex might make sense for those.

Sounds like a cool project! BladeRF is not among the several SDRs I own, but let me know if you want me to take a look at anything.