what is sd_mutex_acquire()/release() good for?

[pabigot]

The SD API (S132-6.0.0) documentation provides little beyond what one could guess from the function and type names. sd_mutex_acquire says "Attempt to acquire a mutex". nrf_mutex_t says "Represents a mutex for use with the nrf_mutex functions" (which almost certainly should have been "... with the sd_mutex functions").

The SD Specification is more informative, saying it's to "avoid disabling global interrupts in the application because ... [that] will interfere with the SoftDevice". But this suggests the mutex doesn't prevent the SD from doing whatever it wants whenever it wants. If I only want to protect against conflicting access from my own code, I'm not clear why I need the SD to help me do this.

I can find no uses of the sd_mutex API in the examples in nRF5-SDK 15.

So what capability is the sd_mutex_* API intended to provide? When should we use it?

(This is in the context of this question for which I'm still searching a solution. If the read of content from BLE_GATTS_VLOC_USER data occurs during a priority 0 interrupt, which I haven't yet been able to disprove, I have to use PRIMASK to ensure the characteristic values are internally consistent.  No?)

[Jørgen Holmefjord]

Hi,

The sd_mutex functions is simply a mutex implementation that can be used by the application. I have copied an answer from a similar question about nRF51 softdevice, which except from different interrupt levels also apply for nRF52 series, that explain the softdevice's function in this implementation:

The mutex functionality itself is handled by the softdevice, and due to the characteristics of SVC-calls in the ARM architecture, it is atomic. When the softdevice is running, you can never interrupt the "lower stack" interrupts. The softdevice only allows application interrupts with priority 1 and 3, and keeping priorities 0 and 2 for it self. 0 is the highest priority in this case. Basically, you can never disable all interrupts, since that will break the softdevice's ability to handle connection events and other real-time requirements. The mutex is atomic, in the sense that grabbing/releasing it is an process that cannot be interrupted as it will run through the softdevice supervisor call (SVC).

Best regards,
Jørgen

[pabigot]

Thanks; I had found that, but didn't find it much more explanatory.  I don't generally need a global mutex; to protect against what my application's doing temporarily blocking individual peripheral interrupts seems to be sufficient.  Though I do use PRIMASK for RMW updates of event flags shared by multiple component, and the SVC call approach is way too heavy-weight for that.

I think that confirms my impression that sd_mutex doesn't protect against SD access to user-maintained memory, which is somebody seeing a mutex implemented by the soft-device might expect it to do, especially if BLE_GATTS_VLOC_USER is used (though that might be the only capability where it's necessary to restrict the soft device).