读 80 列卡片，并根据下列变化把它们打印在每行 125 个字符的行中。在每张卡片图像后插入一个额外的空白符，并字符 | 代替卡片中每对相邻的星号（**）。
a. 为该问题开发一种普通的串行程序解决方案。你会发现程序的编写很有技巧。由于长度从 80 转变到 125，程序中各种元素间的交互是不平衡的：此外，在转换后，卡片图像的长度变化取决于双星号的数量。提高清晰度并减少错误的一种方法是，把该程序编写为三个独立的过程，第一个过程读取卡片图像，在每个图像后补充空格，并将字符流写入一个临时文件。当读完所有卡片后，第二个过程读取这个临时文件，时文件中读取字符流，按每行完成字符替换，并写到第二个临时文件。第三个进程从第二个临 125 个字符进行打印。
b. 串行方案之所以没有吸引力，是因为 I/O 和临时文件的开销。Conway 提出了一种新的程序结构：协同程序，它允许把应用程序编写为通过字符缓冲区连接起来的三个程序（见图 5.25）。在传统的过程中，在调用过程和被调用过程之间存在主／从关系，调用过程可在过程中的任何一点执行调用，被调用过程则从其入口点开始，并在调用点返回调用过程。协同程序显示了一种更为对称的
关系，在每次调用时，从被调用过程中上一次的活跃点开始执行。由于没有调用过程高于被调用过程的感觉，也就没有返回。相反，任何一个协同程序都可通过恢复命令把控制权传递给另一个协同程序。首次调用一个协同程序时，它会在入口点“恢复”，接着该协同程序在其所拥有的上一个恢复命令的地方重新激活。注意，程序中一次只能有一个协同程序处于执行态，并且转移点可以在代码中显式定义，因此这不是一个并发处理的例子。请解释图 5.25 中程序的操作。
c. 这个程序未解决终止条件。假设 I/O 例程 READCARD 把一幅 80 个字符的图像放入 inbuf，它返回 true，否则返回 faLse。修改这个程序，以包含这种可能性。注意最后打印的一行可能因此少于 125 个字符。
d. 使用信号量重写解决方案。
