RFC: standardize on a synchronization mechanism for device access

[pabigot]

There are three types of synchronization necessary for devices, several of which are considered in #22941 and its draft PRs particularly #24511:

• Access control, to ensure multiple threads do not attempt to use a device instance concurrently;
• Internal synchronization, to allow the driver to suspend while an operation it depends on is in progress;
• External synchronization, to return control to the caller with notification performed by the driver when the requested operation completes.

The topic of this issue is access control, which historically has been implemented using k_sem. As originally raised in this comment I'd like to propose that was use k_mutex instead, as this offers:

• priority inheritance, which would allow a block high-priority thread to get access to the resources it needs faster by allowing the current owner to temporarily run with the blocked thread's priority;
• recursive locking, which may simplify some use cases particularly in drivers with multiple user-facing API calls.

The first question is whether this the right move. A follow-up question is whether the generic device API should provide support for any or all of the above synchronizations.

If we use k_mutex for access control we would need #25678 to be worked so its operations can be initiated from interrupt context, as is already allowed for k_sem.

[andrewboie]

While we're thinking about this topic, it looks the the PREEMPT_RT patch to Linux goes even further and replaces some usages of spinlocks with RT-mutexes. There are caveats and I'm not sure how applicable this is to Zephyr, but interesting nonetheless https://lwn.net/Articles/146861/

[carlescufi]

API meeting

• Device APIs' thread-safety shall be enforced and documented per device class
• Thread safety guarantees shall be the same for all device classes that offer them (priority inheritance for example)
• Synchronization shall be disabled when CONFIG_MULTITHREADING is n

[jfischer-no]

• Synchronization shall be disabled when CONFIG_MULTITHREADING is n

I am against forcing it for all drivers APIs.

[gregshue]

When we need exclusive access to resources shared with interrupt context we need to lock interrupts to the level of the ISR(s) accessing it (or we need to disable the ISRs that access it - causing priority inversion). This cannot be done by a k_mutex, so we will need at least two mechanisms. Which one depends on whether the project configures the interrupt service routine to run in interrupt context or meta-irq context.

Also, don't forget about access in an SMP environment and any issues with access originating from User threads.