https://devzone.nordicsemi.com/f/nordic-q-a/39076/is-gpiote-driver-thread-safeDear Nordic experts, While investigating some of my bugs, I had to look into the GPIOTE driver code, and I realized that it has some allocator for mapping GPIOTE channels to pins. Because the GPIOTE driver connects the input buffer, I call it dynamicallyen-USTelligent Community 13Wed, 03 Oct 2018 13:05:02 GMThttps://devzone.nordicsemi.com/thread/151456?ContentTypeID=1Wed, 03 Oct 2018 13:05:02 GMT137ad170-7792-4731-bb38-c0d22fbe4515:9aba2280-4122-47d8-8b96-30d0736c8405Vincent Bela&#239;che<p>Thank you, this confirms what I anticipated from reading the code.</p> <p>I think that the driver documentation should be improved for the user to know which driver functions access shared variables, and as such should be protected somehow from thread interaction (by means of some protocol between OS tasks, or some mutex), and which do not need such care.</p> <p>This would be helpful to have this kind of info for each function that really needs protection to differentiate them from functions, like e.g. nrf_gpio_in_clear, which inherently are thread safe because registers are 32bits in an 32bit architecture, so as long as some GPIO is assigned to some OS Task there is no conflicts.</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/151401?ContentTypeID=1Wed, 03 Oct 2018 11:38:54 GMT137ad170-7792-4731-bb38-c0d22fbe4515:3bd2f70f-ce3a-42f3-8f0e-fdb5f092a4eaSusheel Nuguru<p>Hi Vincent,</p> <p>The drivers were not designed to be thread safe yet. While using in any RTOS, I normally protect any global member that is being accessed in multiple context by a mutex. I would recommend you to do the same to be sure of it.</p><div style="clear:both;"></div>