Identifying timers in CMB_setTimeout_*()

When running multiple Mykonos chips from the same software stack, we need to distinguish which chip we're talking to. For the most part, that works fine, because the driver requires us to pass in mykonosDevice_t or spiSettings_t structs.
The one case where this is not possible is in CMB_setTimeout_ms() and CMB_hasTimeoutExpired(). They take no arguments that let us differentiate between chips. So, if we're running stuff on both chips at the same time, and controlling them from different threads, using a global timer could be problematic (the first thread's timeout value would overwrite the second thread's).
I've noticed that the Mykonos Linux kernel driver has similar problems. The chip selection is solved in a similar fashion as we have, but there is a single global timer for the timeouts.
If these calls would have some identifier, we could easily solve this in the implementation of those API calls.
Are there plans to update the API to allow to differentiate between timers?
  • Reentrant and thread safe are two different things!

    If you want more than one driver instance, the code needs to be reentrant.

    This means it must not have global variables.

    The HAL API lacks a fundamental principle. Each API method needs to have a per instance handle.

    -Michael

  • Please do not use AD9371 API in a multithreaded environment as API functions are not thread safe. It rely upon many user supplied global data structures.

    Even though you can identify a code flow with specific to a chip, it's not guaranteed to continue with same thread as soon as scheduling happens. Consider a case where a thread identify a chip and scheduler reschedule the next thread running the same piece of code for other chip.

  • Thread safety requires a bunch of things, such as locking access to API calls that require exclusive access to devices (like SPI). We're comfortable with all of that, but as mhennerich points out, we need that per-instance handle, or some kind of context. Whenever we pass in a spiSettings_t, or a mykonos_device_t, we can fake that out. For those functions that don't take such an argument, we're stuck.

    Simply not supporting multiple AD9371 is not an option.

  • We have raised this issue with concerned team. We will be able to provide you estimated timeframe in few days. 

  • Would someone please update this thread, if this has actually been addressed? Very interested in this as the Ettus N310 has two AD9371 chips on it.