commit b86bf840d1d562d12efd4e0790ce14455f5fa271
author Tanzinul Islam <tanzinul.islam@gmail.com> Sun Sep 03 15:39:19 2023 +0100
committer Tanzinul Islam <t_17_7@hotmail.com> Sun Sep 03 16:46:02 2023 +0100
tree e21a6f38eb396f8e229c70e78cfc80721ea459b9
parent 8a6feabf04bec8fb125e0df0ad1195c42350725f

Count threads after thread-creation while still holding mutex lock

The `Mutex` is locked with the `MutexLock` before spawning the thread, so that the thread is prevented from completing (by being blocked on `Mutex`) before the new thread count is obtained. However, the existing bug (introduced in 22e6055) releases `Mutex` before obtaining the new thread count, which allows the thread to run to completion in the meantime.

Also, since the `(thread_count_after_create != starting_count + 1)` condition (line 328) skips the remainder of the `for`-loop body on every iteration, `thread_count_after_join` stays uninitialized.

I believe this is why [this test failed][1] on the macOS CI with this trace:

```
[----------] 1 test from GetThreadCountTest
[ RUN      ] GetThreadCountTest.ReturnsCorrectValue
googletest/test/googletest-port-test.cc:350: Failure
Expected equality of these values:
  thread_count_after_create
    Which is: 1
  starting_count + 1
    Which is: 2

googletest/test/googletest-port-test.cc:351: Failure
Expected equality of these values:
  thread_count_after_join
    Which is: 140493185949400
  starting_count
    Which is: 1

[  FAILED  ] GetThreadCountTest.ReturnsCorrectValue (2 ms)
[----------] 1 test from GetThreadCountTest (2 ms total)
```

[1]: https://github.com/google/googletest/actions/runs/6064919420/job/16453860690?pr=3049