Re: [PR] sched: add a reference count to the TCB to prevent it from being deleted. [nuttx]

[via GitHub]

hujun260 commented on PR #17468:
URL: https://github.com/apache/nuttx/pull/17468#issuecomment-3834648124

   > > > One more update for you all:
   > > > 
   > > > 1. In the process of promoting NuttX right now, most business 
stakeholders have extremely high requirements for kernel performance and will 
opt for Zephyr as their first choice. Developers also have numerous doubts 
about the stability and performance of the NuttX kernel.
   > > > 2. When working on your internal solutions, you’d better research how 
other companies have implemented their corresponding solutions. Even 
Bestechnic, your Tier 1 supplier, does not recommend using your framework for 
headphone and Wi-Fi/BT module solutions.
   > > > 3. The next-generation OS will be built on the first principles rather 
than being based on excessive assumptions. Any business implementations with 
poor performance or flaws should be phased out and optimized, instead of having 
the operating system do a great deal of unnecessary fallback work for them.
   > > 
   > > 
   > > It just means we are encountering different usage scenarios. While 
enter_critical_section might work for very simple cases, But, nuttX needs to 
evolve.
   > > Memory safety issues are not imaginary. Let's take the function 
nxsched_foreach as an example. We cannot guarantee that the tcb parameter 
passed to the handler is always valid. Neither enter_critical_section nor 
sched_lock can solve this problem. If the handler performs a wait operation, it 
will invalidate the entire critical section and the scheduling lock.
   > > <img alt="image" width="506" height="443" 
src="https://private-user-images.githubusercontent.com/128452594/543571247-1c4f4e45-b4e6-4601-8392-5904b928f45e.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAwMDkwODksIm5iZiI6MTc3MDAwODc4OSwicGF0aCI6Ii8xMjg0NTI1OTQvNTQzNTcxMjQ3LTFjNGY0ZTQ1LWI0ZTYtNDYwMS04MzkyLTU5MDRiOTI4ZjQ1ZS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjAyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwMlQwNTA2MjlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03MmVmNjUyZjI1NGIyN2E0NTY4YTk5NmIzY2UzNTgxMTgxMWJmZTc4ZjkwNzNiYWEyNzE5YmEzODk0NTkwY2IyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.MJe_5U7pw3Tw5MygYaEX0F8ya6uzxih_mA03pu5OpME";>
   > 
   > <img alt="image" width="862" height="564" 
src="https://private-user-images.githubusercontent.com/758493/543579896-86465017-a130-48de-bc30-7107d0964933.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzAwMzI0MjAsIm5iZiI6MTc3MDAzMjEyMCwicGF0aCI6Ii83NTg0OTMvNTQzNTc5ODk2LTg2NDY1MDE3LWExMzAtNDhkZS1iYzMwLTcxMDdkMDk2NDkzMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwMjAyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDIwMlQxMTM1MjBaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT02NTdmNzQ4OGIxM2MxZjJhZWViZTc1ZDViZjEyNWIwNmUzNjExMGJmYTY0MGFmNDJjZmNjMTI2OGRiODYxNDY1JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.k-ioZ4JeiO_GqCI7DNDHCdCL8et9aT-M7r3EjGNzrdY";>
   > Shouldn't we optimize the implementation here?
   
   This is just one example. Your suggestion hardly solves this category of 
issues at the root. The fundamental problem is that critical sections are 
simply not a safe solution in complex scenarios. Take task_fssync for instance, 
which involves a wait operation.
   
   <img width="368" height="89" alt="image" 
src="https://github.com/user-attachments/assets/66f28c9c-4b88-4cb7-b736-1b463ab10af2";
 />
   
   
   I think you are somewhat overstating the performance impact of this patch. 
The so-called core performance of an RTOS primarily revolves around context 
switching and mutex/pthread_mutex operations, where this change has little 
effect. Moreover, the usage scenarios for nxsched_get_tcb are mostly 
non-frequently-called interfaces.
   


-- 
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: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org