Hi Giovanni,
Why do all the HAL calls wrap the sub-calls to the lld_fn() functions around chSysLock(); fn(); chSysUnlock(); ? Could there be a problem if these calls are unprotected?
Thanks,
~T
calls to LLD protected with locks
Moderators: RoccoMarco, lbednarz, tfAteba
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: calls to LLD protected with locks
Hi,
It depends, not all functions do that but often the high level driver performs some actions that must be performed atomically with the low level driver function, for example:
- Check driver state.
- Change state.
- Call low level driver which will use/change the state from an ISR in some random successive moment.
In order to avoid race conditions the lock is required.
Giovanni
It depends, not all functions do that but often the high level driver performs some actions that must be performed atomically with the low level driver function, for example:
- Check driver state.
- Change state.
- Call low level driver which will use/change the state from an ISR in some random successive moment.
In order to avoid race conditions the lock is required.
Giovanni
Re: calls to LLD protected with locks
I am worried that in some cases those locks turn off interrupts for quite a bit of time (for example, when doing low level driver "start()" calls).
I have "fast interrupt" that I really don't want to miss. Would it make sense to enclose those calls in a mutex instead? (I don't really know, I'm just thinking aloud)
~T
I have "fast interrupt" that I really don't want to miss. Would it make sense to enclose those calls in a mutex instead? (I don't really know, I'm just thinking aloud)
~T
Re: calls to LLD protected with locks
I went and read a bit about masking out interrupts. How about locking interrupts specific to the specific driver, or above certain priorities?
It seems like a recipe for "a lot of pain" but it would allow leaving the kernel and some interrupts untouched while doing atomic updates in other less critical drivers.
~T
It seems like a recipe for "a lot of pain" but it would allow leaving the kernel and some interrupts untouched while doing atomic updates in other less critical drivers.
~T
-
Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: calls to LLD protected with locks
Hi,
There is portability to consider but it is an interesting concept.
Anyway, the Cortex-M3/M4 port does not disable all interrupts, it raises the interrupts mask at "kernel level", interrupts with higher priority are never disabled but cannot call the kernel directly.
This is usually resolved by implementing segmented interrupt handlers where high priority, low latency IRQs can preempt the kernel and then "delegate" the invocation of kernel functions to a lower priority handler (usually by triggering a PENDSV interrupt). This reminds me that I still have to create a demo about this...
About locks duration, some device drivers reopen the lock within the LLD function before doing heavy operations, the lock is taken again before exit. This problem is handled case by case.
Giovanni
There is portability to consider but it is an interesting concept.
Anyway, the Cortex-M3/M4 port does not disable all interrupts, it raises the interrupts mask at "kernel level", interrupts with higher priority are never disabled but cannot call the kernel directly.
This is usually resolved by implementing segmented interrupt handlers where high priority, low latency IRQs can preempt the kernel and then "delegate" the invocation of kernel functions to a lower priority handler (usually by triggering a PENDSV interrupt). This reminds me that I still have to create a demo about this...
About locks duration, some device drivers reopen the lock within the LLD function before doing heavy operations, the lock is taken again before exit. This problem is handled case by case.
Giovanni