mm/iob: remove csection

[hujun260]

Summary

reason:
We decouple semcount from business logic
by using an independent counting variable,
which allows us to remove critical sections in many cases.

Impact

mm/iob

Testing

test by apache/nuttx-apps#2849
Build Host:

OS: Ubuntu 20.04
CPU: x86_64
Compiler: GCC 9.4.0
Configuring NuttX and compile:
$ ./tools/configure.sh -l qemu-armv8a:nsh_smp
$ make
Running with qemu
$ qemu-system-aarch64 -cpu cortex-a53 -smp 4 -nographic
-machine virt,virtualization=on,gic-version=3
-net none -chardev stdio,id=con,mux=on -serial chardev:con
-mon chardev=con,mode=readline -kernel ./nuttx

[nuttxpr]

[Experimental Bot, please feedback here]

This PR appears to partially meet the NuttX requirements. While it provides a reasonable summary and identifies the impacted area, it lacks crucial details in the Impact and Testing sections.

Here's a breakdown of what's missing and how to improve it:

Missing Information:

• Impact: The PR only mentions "mm/iob" as the impacted area. It needs to specifically address all the impact points listed in the requirements:

  • Is this a new feature or a change to an existing one?
  • User impact (will users need to change anything in their applications?)
  • Build impact (any changes to the build process or configuration?)
  • Hardware impact (does it affect specific architectures, boards, or drivers?)
  • Documentation impact (does this require documentation updates? Were they provided?)
  • Security impact (are there any potential security implications?)
  • Compatibility impact (backward/forward compatibility concerns?)
  • Anything else to consider?

• Testing: The testing information is insufficient. While it mentions a related NuttX Apps PR, it doesn't provide the results of the testing. The logs before and after the change are empty. This section needs to include:

  • Specific target details (architecture, board, configuration). "qemu-armv8a:nsh_smp" is a start, but more details might be necessary.
  • Actual log output demonstrating the behavior before and after the change, highlighting the improvement or fix. This is crucial for verifying the change works as intended. Simply stating "test by ..." isn't enough.

How to Improve:

• Impact: Fill in all the required impact categories with specific "YES/NO" answers and detailed explanations where applicable. Even if the answer is "NO," briefly explain why (e.g., "Impact on user: NO - This is an internal change and does not affect user APIs.").
• Testing: Provide concrete test results. Include the actual log output before and after the change. Clearly demonstrate how the change addresses the issue or implements the new feature. Consider adding more test cases if necessary to cover different scenarios.

Example of Improved Testing Section:

Testing

I confirm that changes are verified on local setup and works as intended:
* Build Host(s): Ubuntu 20.04, x86_64, GCC 9.4.0
* Target(s): QEMU ARMv8-A (Cortex-A53), nsh_smp configuration

Testing logs before change:

<Insert relevant log output showing the problem before the change. For example, demonstrating contention or performance issues related to the semcount.>

Testing logs after change:

<Insert relevant log output showing the improved behavior after the change. For example, demonstrating improved performance or the absence of contention.>

This PR fixes the contention issues observed previously. The logs after the change show a significant improvement in throughput/responsiveness/etc. (Be specific about the improvement).

By providing more complete information in the Impact and Testing sections, the PR will be much easier to review and more likely to be accepted.

[yamt]

reason: We decouple semcount from business logic by using an independent counting variable, which allows us to remove critical sections in many cases.

if it's so common, i feel it's better to migrate to a simpler primitve like a condvar. how do you think?

[hujun260]

reason: We decouple semcount from business logic by using an independent counting variable, which allows us to remove critical sections in many cases.

if it's so common, i feel it's better to migrate to a simpler primitve like a condvar. how do you think?

The implementation of sched/event/* has similar semantics but has more powerful and complex functionalities, making it unsuitable for some scenarios.