APUE 中 TELL_WAIT 五个函数方法总结

发表于 更新于 分类于 ， 阅读次数： 本文字数： 3k 阅读时长 ≈ 15 分钟

本文总结 APUE 中 TELL_WAIT 相关的五个函数，并说明它们为什么能够作为父子进程同步的方法；同时也补充梳理几种常见的父子进程同步手段，方便横向比较。

在 APUE 中，TELL_WAIT 这一组函数的目标非常明确：为父进程和子进程提供一种简单、可靠的同步机制。其典型用途是让父进程先做某件事，再通知子进程继续；或者让子进程先完成某一步，再通知父进程继续。

这种机制本质上解决的是：

  • 父子进程虽然有亲缘关系，但调度顺序是不确定的；
  • 如果不做同步，就可能出现竞态条件（race condition）；
  • 因而需要一种“你先做完、再叫我”的协调方式。

一、TELL_WAIT 五个函数概览

APUE 中通常定义如下五个接口：

  • TELL_WAIT(void)
  • TELL_PARENT(pid_t pid)
  • WAIT_PARENT(void)
  • TELL_CHILD(pid_t pid)
  • WAIT_CHILD(void)

它们通常结合信号机制实现，常见做法是使用：

  • SIGUSR1
  • SIGUSR2
  • 信号屏蔽字
  • sigsuspend

这样做的关键目的，是避免“信号先到、进程后等待”导致的丢失唤醒问题。

二、这五个函数分别做什么

TELL_WAIT(void)

这是初始化函数，用来在父子进程同步开始之前完成准备工作。

它通常负责：

  • 为同步所用的信号安装处理函数；
  • 将相关信号加入阻塞集合；
  • 初始化全局标志变量；
  • 为后续 WAIT_PARENT / WAIT_CHILD 的等待逻辑创造安全条件。

作用理解

可以把它看成“搭建同步环境”。

如果没有这一步，后面的等待与通知很容易因为时序问题出错。例如：

  • 子进程还没开始等待，父进程就已经发出了信号；
  • 结果信号被错过，子进程可能永久阻塞。

因此 TELL_WAIT() 的重点不是“通知”，而是预先建立不会错过通知的机制。

TELL_PARENT(pid_t pid)

该函数由子进程调用，用于通知父进程：“我已经完成了当前阶段，你可以继续了。”

典型实现通常是向父进程发送一个约定好的信号，例如：

1
kill(pid, SIGUSR2);

其中 pid 一般就是父进程的 PID。

使用场景

例如：

  • 子进程先修改某个共享资源；
  • 修改完成后调用 TELL_PARENT(getppid())；
  • 父进程在 WAIT_CHILD() 或对应等待流程结束后再继续执行。

本质

它扮演的是“子 -> 父 的完成通知”角色。

WAIT_PARENT(void)

该函数由子进程调用，表示：“我要先停下来，等父进程通知我以后再继续。”

它一般会：

  • 检查同步标志是否已被置位；
  • 若没有，则通过 sigsuspend() 临时切换信号掩码并挂起；
  • 收到父进程发来的同步信号后恢复执行。

为什么不用简单的 pause()

因为 pause() 容易产生竞态问题：

  • 如果信号在调用 pause() 之前已经送达，
  • 那么后续 pause() 可能就会一直阻塞。

而 APUE 的写法通常通过“先阻塞信号，再用 sigsuspend() 原子地解除阻塞并等待”来避免这个问题。

本质

它是“子等父”的等待入口。

TELL_CHILD(pid_t pid)

该函数由父进程调用，用于通知子进程：“我这边已经完成了，你可以继续执行了。”

典型实现通常是：

1
kill(pid, SIGUSR1);

这里的 pid 一般是 fork() 返回得到的子进程 PID。

使用场景

例如：

  • 父进程先完成初始化；
  • 完成后调用 TELL_CHILD(child_pid)；
  • 子进程原本在 WAIT_PARENT() 中阻塞，收到信号后继续运行。

本质

它扮演的是“父 -> 子 的完成通知”角色。

WAIT_CHILD(void)

该函数由父进程调用，表示：“我要先等待，直到子进程通知我再继续。”

它的实现思想与 WAIT_PARENT() 类似，也是通过：

  • 全局标志位；
  • 信号阻塞；
  • sigsuspend()；

来可靠地等待子进程的通知。

典型用途

例如：

  • 父进程希望等子进程先写完一段数据；
  • 于是父进程调用 WAIT_CHILD()；
  • 子进程完成后调用 TELL_PARENT()；
  • 父进程被唤醒并继续执行。

本质

它是“父等子”的等待入口。

三、五个函数之间的配合关系

这五个函数并不是孤立的，而是两两配合使用：

方向 通知函数 等待函数 含义
父通知子 TELL_CHILD(pid) WAIT_PARENT() 子进程等待父进程发令
子通知父 TELL_PARENT(pid) WAIT_CHILD() 父进程等待子进程发令

而 TELL_WAIT() 则是整个同步机制的初始化入口。

可以把它们理解成一套小型协议：

  1. 先 TELL_WAIT()，把通信规则搭起来；
  2. 谁需要等，就调用对应的 WAIT_*()；
  3. 谁完成了，就调用对应的 TELL_*() 发通知。

四、为什么说这是父子进程同步的方法

因为这组函数专门用于协调父进程与 fork() 出来的子进程之间的执行先后关系。

“同步”在这里并不是指数据完全共享，而是指：

  • 某个进程先执行到某一步；
  • 另一个进程必须等它完成后才能继续；
  • 这种“顺序约束”正是同步的核心。

例如下面这种逻辑：

1
2
3
4
5
6
7
8
9
10
TELL_WAIT();
pid = fork();

if (pid == 0) {
    WAIT_PARENT();
    /* 子进程继续执行 */
} else {
    /* 父进程先做一些事 */
    TELL_CHILD(pid);
}

这里就明确规定了：

  • 父进程先执行某一步；
  • 子进程必须等到父进程通知后才能继续。

因此，TELL_WAIT 这一组函数就是一种基于信号的父子进程同步方法。

五、这种方法的特点

优点

  • 轻量：不需要额外创建复杂 IPC 对象；
  • 适合父子关系：fork() 后天然就知道对方 PID；
  • 可表达顺序控制：尤其适合演示和处理简单同步场景；
  • APUE 风格典型：很好地展示了如何安全地用信号避免竞态。

局限

  • 只适合较简单的同步，不适合复杂状态机；
  • 信号只适合表达事件，不适合携带大量数据；
  • 编写不当容易出现竞态、信号丢失、可重入等问题；
  • 可读性和可维护性通常不如更结构化的 IPC 机制。

因此在工程实践里，TELL_WAIT 更多是一个经典教学模型，帮助理解“如何安全地使用信号完成同步”。

六、其他父子进程同步的方法总结

除了 APUE 里的 TELL_WAIT 方案，父子进程还可以通过很多方式同步。下面按常见程度做一个总结。

1. wait() / waitpid()

这是最基础、最常见的父子同步方式。

作用

父进程通过 wait() 或 waitpid()：

  • 等待子进程结束；
  • 回收子进程资源；
  • 获取子进程退出状态。

特点

  • 非常适合“父等子结束”这一类同步；
  • 语义清晰；
  • 是处理僵尸进程的标准方式。

局限

  • 它只能表达“等子进程终止”，
  • 不适合“子进程做到一半通知父进程继续”这种更细粒度的同步。

所以，wait()/waitpid() 更像是生命周期终点同步。

2. 信号

TELL_WAIT 本身就是信号同步的一个精心封装版本。

父子进程还可以直接使用：

  • SIGUSR1
  • SIGUSR2
  • SIGCHLD

来做事件通知。

特点

  • 响应快；
  • 实现简单；
  • 适合“一次事件通知”。

局限

  • 需要认真处理屏蔽、竞态和中断；
  • 不适合传输复杂数据；
  • 稍不注意就容易写出脆弱代码。

3. 管道（pipe）

管道是父子进程之间极常见的同步与通信方式。

作用

父进程和子进程共享同一个管道端点关系：

  • 一方写；
  • 另一方读；
  • 当读操作阻塞时，就形成了同步效果。

同步方式

例如：

  • 父进程先阻塞读；
  • 子进程写入一个字节作为“完成信号”；
  • 父进程读到后继续执行。

特点

  • 既能同步，又能顺便传递少量数据；
  • 语义直观；
  • 非常适合父子进程。

局限

  • 需要管理读写端关闭；
  • 稍复杂一些；
  • 主要适合有亲缘关系的进程。

4. FIFO（命名管道）

FIFO 是带名字的管道。

特点

  • 不要求必须由同一个父进程 fork() 出来；
  • 父子进程当然也可以使用；
  • 可以借助打开、读写阻塞特性实现同步。

适用场景

如果你希望同步机制不仅限于当前父子进程，还能扩展到其他无亲缘关系进程，FIFO 比匿名管道更灵活。

5. System V 信号量 / POSIX 信号量

信号量是更通用、更正式的同步手段。

作用

通过 P/V 操作（或等待/投递操作）控制临界资源访问和执行顺序。

特点

  • 非常适合严格同步和互斥；
  • 能表达计数资源；
  • 比简单信号更结构化。

局限

  • 接口相对复杂；
  • 对于只做一次父子通知的场景，显得偏重。

如果同步逻辑比较复杂，比如多进程竞争多个资源，信号量通常比 TELL_WAIT 更合适。

6. 共享内存 + 同步原语

共享内存本身更偏向“通信”，不是天然同步工具；但配合：

  • 信号量；
  • 互斥锁；
  • 条件变量；
  • futex；

就可以实现高效同步。

特点

  • 数据交换效率高；
  • 适合高性能、多数据量场景；
  • 工程上很常见。

局限

  • 设计和调试难度较高；
  • 必须额外引入同步机制，否则容易出现数据竞争。

7. socketpair

socketpair() 可以创建一对相互连通的本地套接字。

特点

  • 父子进程之间使用方便；
  • 支持双向通信；
  • 既能传数据，也能通过阻塞读写实现同步。

适用场景

如果你既需要同步，又需要双向消息交互，socketpair() 往往比单向管道更灵活。

8. 文件锁 / 记录锁

父子进程也可以借助文件锁来同步，例如：

  • fcntl 记录锁；
  • flock 文件锁。

特点

  • 适合围绕某个共享文件进行协调；
  • 在某些守护进程、单实例控制场景里很有用。

局限

  • 不如信号量和管道直观；
  • 更适合资源访问控制，而不是简单的“你先我后”通知。

七、几种方法的简要比较

方法 是否适合父子进程 是否能传数据 适合的同步粒度 复杂度
TELL_WAIT（信号） 是 否/极弱 事件级 低到中
wait()/waitpid() 是 否 子进程结束级 低
管道 pipe 是 是 事件级/数据级 中
FIFO 是 是 事件级/数据级 中
信号量 是 否 严格同步/互斥 中到高
共享内存 + 锁 是 是 高性能复杂同步 高
socketpair 是 是 双向事件/数据级 中
文件锁 可用 否 资源访问级 中

如果只是在 APUE 语境下理解“父子进程同步”，可以先记住下面这条主线：

  • 等子进程结束：优先想到 wait()/waitpid()；
  • 做轻量级顺序通知：优先想到 TELL_WAIT 这种信号方案；
  • 既要同步又要传数据：优先想到 pipe 或 socketpair；
  • 同步关系更复杂：优先想到信号量或共享内存配合同步原语。

八、小结

TELL_WAIT 这一组五个函数，本质上是一套基于信号的父子进程同步接口：

  • TELL_WAIT()：初始化同步环境；
  • TELL_PARENT()：子通知父；
  • WAIT_PARENT()：子等父；
  • TELL_CHILD()：父通知子；
  • WAIT_CHILD()：父等子。

它们解决的是父子进程执行顺序不确定带来的竞态问题，是 APUE 中非常经典的一种同步设计。

从更大的视角看，父子进程同步并不只有这一种方法。wait()/waitpid()、信号、管道、FIFO、信号量、共享内存、socketpair、文件锁等都可以承担同步职责。不同方法适合不同粒度和复杂度的场景，而 TELL_WAIT 的价值在于：它用一个简洁而经典的模型，展示了如何安全地利用信号完成父子进程同步。