This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

sd_mutex implementation question

I am using a mutex to protect a serial debug printout.

Is it safe to use sd_mutex_acquire in a blocking manner, provided it is only called from main and softdevice callbacks  (interrupt pri level 3), or is there a scenario in which this could cause a problem?

What happens if a softdevice callback functions needs a mutex-protected resource that main currently has locked; will the callback task be suspended and main (eventually) scheduled?

Parents
  • When you say blocking manner, i am assuming you say that you loop until you get it, right? I think this is safe to do in main context. In the softdevice callback, which is the SWI2 interrupt handler, you should not do this because if you wait long enough, then your program will miss other incoming SWI2 events from softdevice. This could result that if you are using sd_app_evt_wait() hoping to get an event, then your system could sleep for ever as that event was notified by softdevice but just was lost in the blocking wait.

    This is something I could think of, maybe others will add more reasons, but It is recommended not to do this in any interrupt context with priority higher than or equal to APP_PRIORITY_LOW (3).

Reply
  • When you say blocking manner, i am assuming you say that you loop until you get it, right? I think this is safe to do in main context. In the softdevice callback, which is the SWI2 interrupt handler, you should not do this because if you wait long enough, then your program will miss other incoming SWI2 events from softdevice. This could result that if you are using sd_app_evt_wait() hoping to get an event, then your system could sleep for ever as that event was notified by softdevice but just was lost in the blocking wait.

    This is something I could think of, maybe others will add more reasons, but It is recommended not to do this in any interrupt context with priority higher than or equal to APP_PRIORITY_LOW (3).

Children
No Data
Related