关于阻塞系统调用和潜在竞争条件

Question

我们正在对网络套接字使用阻塞系统I/O调用。我们想要的行为是当对套接字调用close()时,阻塞调用需要返回并抛出一个异常（引用）,

看看OpenJDK，这就是它的实现方式。它使用用户信号唤醒阻塞线程。相应的信号处理程序是no-op。在阻塞调用之前，它注册可能被阻塞的线程。当关闭文件描述符时，关闭线程向阻塞的I/O线程发送信号，这导致阻塞调用返回eintr。

不过，我还是认为下面的代码块源代码中存在一个潜在的竞争条件：

  startOp(fdEntry, &self);  // (1)
  ret = FUNC;               // (2)
  endOp(fdEntry, &self); 

在I/O线程中，(1)执行，然后关闭线程调用close并在（2）开始执行之前将信号发送给I/O线程。接收并丢弃该信号。当（2）开始在I/O线程中执行时，它将进行阻塞系统调用。在这个阶段，fdEntry可能关闭，或者即将关闭。

我理解对吗？是我做了一个错误的观察，还是种族状况的可能性很低，所以我们可以放心地忽略它？

Answer 1

回答自己：原来它确实是一个bug。修复是在close端：我们首先关闭文件描述符，然后通知阻塞线程。如果阻塞线程错过信号并启动阻塞调用，它将立即以ebadf返回，因为文件描述符已经关闭。