非重叠串口下多线程调用ReadFile()/WriteFile()是否会互相阻塞

非重叠（同步）模式串口句柄被多线程并发调用ReadFile()/WriteFile()时确实会出现跨线程阻塞，但你观测到的CPU占用飙升至100%的现象，并非阻塞本身直接导致——阻塞状态的线程会被系统挂起，不会消耗CPU时间片，占满CPU的本质是并发IO触发了Windows XP的串口驱动bug，或是上层代码对IO返回异常的处理逻辑存在忙等缺陷。

多线程并发调用同步串口IO的行为确认 #

• Windows内核层对所有文件类型句柄（串口属于内核文件对象范畴）的同步IO请求做强制串行化处理：同一时间同一个句柄上仅允许一个同步IO请求处于待完成状态，其他线程后续发起的ReadFile()/WriteFile()会直接在内核层进入阻塞状态，等前一个IO请求完成后才会依次调度执行，不会出现IO数据错乱，但跨线程阻塞的现象是真实存在的。
• Windows XP存在专属的串口驱动遗留bug：如果某一线程正阻塞在ReadFile()调用等待串口数据，另一线程直接对同一句柄调用CloseHandle()，内核不会正常唤醒阻塞的读线程，反而会让该线程进入内核态自旋，直接占满单个CPU核心，自旋超时窗口恰好是你观测到的10~20秒，超时后线程才会正常退出，CPU占用恢复，该bug在Vista及之后的Windows版本中才被修复。
• 另一个高频触发场景：如果多线程并发访问同步串口句柄时没有加访问保护，某线程读操作超时退出的瞬间，另一线程刚好发起写操作，XP串口驱动会偶发进入异常状态，后续所有IO请求会立即返回失败。如果上层代码对IO失败的处理是无休眠的轮询重试（比如while(!ReadFile(...)){}结构，分支里没有调用Sleep()出让CPU），会直接触发用户态忙等，占满CPU直到驱动状态在10~20秒后自动复位。

适配你当前环境（Windows XP + C++03 无现代调试工具）的排查&修复方案 #

• 优先排查所有串口操作相关的循环逻辑，检查ReadFile()/WriteFile()返回失败、超时的分支，只要存在无休眠的空循环，第一时间加上Sleep(1)出让CPU，这类问题是CPU占满故障的最高发诱因。
• 用XP原生支持的CRITICAL_SECTION给每个串口句柄的所有IO操作（含ReadFile()/WriteFile()/CloseHandle()）加访问锁，保证同一时刻仅有一个线程能操作对应串口句柄，从根源上避免并发IO触发驱动bug。
• 禁止在读写线程之外的线程直接调用CloseHandle()关闭串口。关闭串口前，先通过SetCommMask()修改事件掩码唤醒阻塞的读写线程，等所有读写线程正常退出后，再执行句柄关闭操作。

验证方法：可以写一个最小测试程序，开两个线程同时对同一个同步模式串口调用ReadFile()阻塞等待，第三个线程等待3秒后直接调用CloseHandle()关闭句柄，在XP环境下多次测试可稳定复现单核心CPU占满10~20秒的现象，和你描述的故障特征完全吻合。

内容的提问来源于stack exchange，提问作者Subfortune