Make bIsIdentified atomic

[mcfnord]

🤖 AI: Requested by @pljones by email, as the follow-up point on #3930. bIsIdentified is written on the socket thread and read on the mix path with no lock common to the two, which ThreadSanitizer reports as a data race. It becomes std::atomic<bool>, matching bIsEnabled two lines above it.

Short description of changes

One line: the bIsIdentified declaration becomes std::atomic<bool>. <atomic> is already included, and bIsEnabled and iConTimeOut are already declared this way, so no call site changes.

The writers run on the socket thread: ResetInfo from CServer::InitChannel on every new connection, and SetChanInfo when channel info arrives; both reached under CServer::Mutex from CServer::PutAudioData. The racing read is the early return in PrepAndSendPacket, reached from MixEncodeTransmitData — which OnTimer runs after releasing that mutex, and on the pool threads when multithreading is on. The other read is on the socket thread and is not part of this.

ThreadSanitizer, server under 8-bot connect/send/disconnect churn with recording on, trimmed to the two stacks:

WARNING: ThreadSanitizer: data race
  Write of size 1 at 0x7ffffffac352 by thread T2 'CSocketThread':
    #0 CChannel::ResetInfo() src/channel.cpp:364
    #1 CServer::InitChannel(int, CHostAddress const&) src/server.cpp:1496
    #2 CServer::FindChannel(CHostAddress const&, bool) src/server.cpp:1473
    #3 CServer::PutAudioData(...) src/server.cpp:1592
    #4 CSocket::ProcessPacket(CHostAddress const&, int) src/socket.cpp:696
  Previous read of size 1 at 0x7ffffffac352 by main thread:
    #0 CChannel::PrepAndSendPacket(...) src/channel.cpp:719
    #1 CServer::MixEncodeTransmitData(int, int) src/server.cpp:1289
    #2 CServer::OnTimer() src/server.cpp:766

Those line numbers are from a build carrying #3930, where ResetInfo is out of line — main alone cannot answer the question, because with recording on the use-after-free that #3930 closes ends the run at about 55 s, before this race samples. Two 600-second runs of the same rig, one binary each:

build	data-race reports	reports naming PrepAndSendPacket
#3930	90	1
#3930 + this change	80	0

An earlier pair of runs on the same two binaries gave the same 1 and 0.

No misbehaviour has been observed from the race itself. The flag is read once per channel per mix cycle and the worst case is one packet sent or skipped on a stale value.

Nothing is added to the audio deadline path. In the generated code, gcc 13.3 -O2 x86-64, the mix-path read goes from cmpb $0x0,0x7b2(%rdi) to movzbl 0x7b2(%rdi),%eax plus test %al,%al — no lock prefix, no fence — and PrepAndSendPacket disassembles to 101 instructions either way. The one locked instruction the change introduces is the store, xchg %al,(%r12) in SetChanInfo, on the socket thread.

CHANGELOG: SKIP

Context: Fixes an issue?

Follow-up to #3930, which takes the channel Mutex around the writers. This closes the read side, which no lock covers. The two are independent and can merge in either order.

Does this change need documentation? What needs to be documented and how?

No.

Status of this Pull Request

Ready for review.

What is missing until this pull request can be merged?

Review.

Checklist

• I've verified that this Pull Request follows the general code principles
• I tested my code and it does what I want — evidence above
• My code follows the style guide
• I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
• I've filled all the content above

---

🤖 This message was written by AI and reviewed by @mcfnord.