pthread: remove enter_critical_section in pthread_barrier_wait

[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

pthread_barrier_wait

Testing

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. Here's a breakdown:

Strengths:

• Provides a reason for the change: Decoupling semcount from business logic to remove critical sections is a valid justification.
• Specifies the impacted function: pthread_barrier_wait is clearly identified.
• Lists the build host environment: OS, CPU, and compiler details are provided.
• Includes build instructions and how to run it: This offers helpful context for reviewers.

Weaknesses (requiring further information in the PR):

• Missing details in the Summary: While the reason is provided, the "what" and "how" are missing. The summary should explain how the decoupling is achieved and what changes are made to the code. A related NuttX issue number should be included if one exists.
• Incomplete Impact Assessment: While pthread_barrier_wait is mentioned, the PR needs to explicitly answer all the impact questions (user impact, build impact, hardware impact, documentation impact, security impact, compatibility impact). Just stating the impacted function is insufficient. Even if the answer is "NO," it should be stated explicitly.
• Missing "before" and "after" testing logs: The provided example logs are placeholders. Actual logs demonstrating the change's effect (e.g., performance improvement, corrected behavior) are crucial. The testing section also lacks information about the target being tested (qemu-armv8a is mentioned in the build instructions but not explicitly in the Testing section). It would also benefit from explaining the test case used to generate these logs.

To fully meet the NuttX requirements, the PR needs to:

1. Expand the Summary: Explain the technical implementation details and how the change works. Include a related NuttX issue number if applicable.
2. Complete the Impact Assessment: Explicitly answer all the impact questions (even with "NO" if no impact). Provide details if any impact is "YES."
3. Provide real testing logs: Include "before" and "after" logs demonstrating the change's effect and explaining the test case used. Clearly state the target architecture and board configuration used for testing.

By addressing these points, the PR will be much clearer and easier for reviewers to evaluate.

[xiaoxiang781216]

but, we should avoid to use global variable.