hujun260 commented on PR #17468: URL: https://github.com/apache/nuttx/pull/17468#issuecomment-3832745870
> > > > > Zephyr is no more safety either. If your proposal can be applied to any other RTOS, I will approve this submission. > > > > > > > > > > > > We found an issue with NuttX, so why drag other RTOSes into this? I'm not even developing on Zephyr. > > > > > > > > > > > > 1. None of the leading mainstream RTOSes have adopted this change, as it would introduce unnecessary performance overhead. > > > 2. Your commit will affect the project I’m maintaining and cause a slowdown of the whole system. > > > 3. A number of development boards in the community are IoT devices, whose clock speed and memory space are insufficient to support this feature. > > > > > > Additionally, please stop setting the status manually – GitHub will send out unnecessary push notifications and emails because of this. > > > > > > I will proceed with submitting my proposal. 1 On NuttX, this is a fundamental strategy to ensure the safe usage of TCBs, and it also reduces interrupt disable time. 2 This submission will not impact the core system performance; I have already provided RTOS benchmark data. 3 The increase in code size is controllable and will not cause compilation failures for developers in the community. > > If the only way you can avoid hitting performance is to add a noref method, then what’s the point of having ref in the first place? Should we use noref everywhere instead? Why do I have to bear the extra overhead for the implementation of ref? Setting aside the naming issue for now, Currently, nxsched_get_tcb_noref is only used to implement nxsched_verify_pid. If we adopt two different usage patterns for TCBs in the future: 1 nxsched_get_tcb_noref + enter_critical_section (unsafe) 2 nxsched_get_tcb and nxsched_put_tcb This would break code consistency and make maintenance difficult. I believe the pattern (nxsched_get_tcb_noref + enter_critical_section) should only be reserved for extreme, isolated cases where performance is critical. Our priority should be correctness first, with performance being optimized on a case-by-case basis. -- 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]
