yamt commented on issue #14593: URL: https://github.com/apache/nuttx/issues/14593#issuecomment-2456645110
> > i guess it implies `enter_critical_section` works as the single global lock covering the whole system. > > is it right? > > It can be understood like this. > > However, due to the complex of the enter_critical_section function, it can encompass any area, especially scenarios where context switching occurs within the protected area, which may lead to the failure of protection. This is a vulnerability of the critical section. > > The current recommendation is that, if it is not related to protecting the tcb/group good programming practices can avoid to use critical sections. what do you recommend to use instead? mutex? semaphore? spin lock? how do you think about introducing a bit higher-level primitives for the kernel? eg. solaris-like adaptive mutex > > also, to me it isn't clear if `enter_critical_section` is supposed to disable interrupts on the remote CPUs. the comment in `irq_csection.c` says > > > Take the CPU IRQ lock and disable interrupts on all CPUs. > > > > > > on the other hand, other comment in the file says > > > NOTE 1: Ideally this should disable interrupts on all CPUs, but most > > > architectures only support disabling interrupts on the local CPU.` > > > > > > they seem contradicting each other. > > enter_critical_section only disable local CPU interrupts and cannot disable remote CPU interrupts. so, the current semantics of enter_critical_section is: * it disables interrupts on the calling CPU. * it does NOT disable interrupts on remote CPUs. * it acquires the system-global, recursive lock which is automatically released/re-aquired when the current thread blocks/wakes up. (similarly to the big kernel lock in the traditional unix.) is it right? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
