Thank you for your reply and providing additional information. Based on your suggestion, I believe a reasonable solution about sched_lock should be step by step.
1 Add sched_lock()'s ability to the enter_critical_section() 2 Correct the incorrect usage of sched_lock, since many places sched_lock and enter_critical_section are used simultaneously 3 Remove the sched_lock call from userspace Finally, change the sched_lock's name. BR! Gregory Nutt <spudan...@gmail.com> 于2023年4月19日周三 21:42写道： > > > I think sched_lock() should be completely removed > > most case we can replace sched_lock() with enter_critical_section(), > > at the sametime we add sched_lock()'s ability to the > enter_critical_section() > > we can replace sched_lock() with mutex ,sem or spinlock。 > > directly removal > > I would not remove sched_lock(). I think is it very important in a real > time system. Most RTOSs support something like this internally. > > enter_critical_section() is not a replacement for sched_lock() because > it disables interrupts and, hence, harms real time performance. > Interrupts must be disabled as little as possible because it destroys > deterministic OS behavior. sched_lock(), on the other hand, has little > or now real time performance implications if used properly. > > sched_lock() postpones a task from losing the CPU until sched_unlock() > is called. Misuses would include locking the scheduler for too long or, > in the SMP case, misunderstanding the functionality of sched_lock() and > assuming that it is always equivalent to a critical section. Locking > the scheduler for too long is probably not as damaging to performance > has holding the critical section too long! > > Both are very light weight in the single CPU modes. But in SMP, > enter_critical_section() is huge performance pig and should be avoided > when at all possible. sched_lock() is much more real time friendly in SMP. > > Your primary complaint and the thing that no one argues with is that > nxsched "sched_lock() is very easy to misuse and difficult to > understand." However, that is not a sane justification to remove an > important OS function. You don't have a valid, technical justification > for doing that. > > However, we should address your concern (but NOT by removing > sched_lock()). How can be make sched_lock() more intuititive and less > prone to miunderstanding by naive users? > > I think that all we can do is change the naming or perhaps modify semantics. > > First of all, sched_lock() is a non-standard, internal OS and should > never be exposed to applications. It is for the use by informed > developers within the OS only. The naive user should not even be aware > that it exists. So at a minimum, (1) it should be renamed > nxsched_lock(), (2) the user syscall interface should be removed from > syscall/ and include/sys, and (3) the prototype should be removed from > include/sched.h and moved to include/nuttx/sched.h > > The naming could be further improved. The name > nxsched_disable_preemption() and nxsched_enable_preemption(), while a > bit long, do make the functionality of the internal interfaces much > clearer and those are the names that I would recommend. > > >
