State Threads之编程注意事项

原文： Programming Notes

1. 移植

State Thread 库可移植到大多数类 UNIX 平台上，但是该库有几个部分需要依赖于平台特性，以下列出了这些部分：

1. 线程上下文初始化。
   jmp_buf 数据结构的两个成员（程序计数器和堆栈指针）必须在创线程的时候进行手动设置。setjmp.h 文件中的
   jmp_buf 数据结构在不同平台有不同的定义。一般，程序计数器是名字为 PC 的结构体成员，堆栈指针是名字为 SP
   的结构体成员。可以参考 Netscape's NSPR library source 的源码。
   注意，在一些 BSD 派生的平台上，应该使用 setjmp(3)/longjmp(3) 替代 _setjmp(3)/_longjmp(3)（这调用仅操作堆栈和
   寄存器，不保存和恢复进程的信号掩码）。
   Linux 上的 glibc 库 从 2.4 开始，被 setjmp(3)/longjmp(3) 使用的 jmp_buf 数据结构不能被直接访问（除非在程序执行
   前设置特殊的环境变量 LD_POINTER_GUARD）。为了避免对特定环境的依赖，在所有的 Intel CPU 架构上 State
   Threads 库提供了setjmp/longjmp 的替代函数。由于 setjmp/longjmp 在许多 CPU 架构上都是可用的，因此在其他 CPU
   架构上也很容易被支持。

2. 高精度的时间函数。
   一些平台（IRIX, Solaris）提供了一个基于硬件计数器的高精度时间函数。该函数返回过去某一时刻（通常是机器启动
   的时间）到现在的时间计数。它和一天的时刻无关，因此无法重置或清零。这对时间有高效、精准要求的任务十分有
   用。
   若一些特别的平台没有该函数，则可以使用 gettimeofday(3) 函数（尽管在某些平台上，该函数依赖于系统调用）。

3. 堆栈的增长方向。
   该库需要确定堆栈的增长方向是朝下（还是朝上）或者是往高内存地址。我们可以写一个测试程序检测该平台的堆栈增
   长方向。

4. 非阻塞特性继承。
   在一些平台（如 IRIX），由 accept 调用创建的 socket 套接字继承监听套接字的非阻塞特性。我们可以使用测试程序或
   用户手册来确认是否具有该特性。

5. 匿名内存映射。
   State Threads 库在开辟线程堆栈内存时，使用匿名内存映射（mmap(2)）。这个映射在 SVR4 和 BSD4.3 派生的平台
   上有所不同。通过使用 malloc(3) 来进行堆栈分配可以避免内存映射，在这种情况下，应该定义 MALLOC_STACK 宏。

所有与机器相关的特性测试宏都应该在 md.h 头文件中定义。所有 CPU 架构的关于 setjmp/longjmp 替代函数的汇编代码都应该
放在 md.S 文件中。

当前版本的库已支持以下平台的移植：

• IRIX 6.x (both 32 and 64 bit)
• Linux (kernel 2.x and glibc 2.x) on x86, Alpha, MIPS and MIPSEL, SPARC, ARM, PowerPC, 68k, HPPA, S390, IA-64,
  and Opteron (AMD-64)
• Solaris 2.x (SunOS 5.x) on x86, AMD64, SPARC, and SPARC-64
• AIX 4.x
• HP-UX 11 (both 32 and 64 bit)
• Tru64/OSF1
• FreeBSD on x86, AMD64, and Alpha
• OpenBSD on x86, AMD64, Alpha, and SPARC
• NetBSD on x86, Alpha, SPARC, and VAX
• MacOS X (Darwin/Tiger) on PowerPC and 32-bit and 64-bit x86
• Cygwin

2. 信号

使用 State Threads 的应用程序中信号的处理应该与传统的 UNIX 进程应用程序相同。这里没有每个线程的信号掩码，所有线
程共享同一个信号处理函数，并且在信号处理函数中只能使用异步信号安全的函数。当然，可通过将信号事件转换为 I/O 事件
的方法来支持同步信号。下面的代码演示了这种技巧（为了清晰起见，忽略了错误处理）：

/* Per-process pipe which is used as a signal queue. */
/* Up to PIPE_BUF/sizeof(int) signals can be queued up. */
int sig_pipe[2];

/* Signal catching function. */
/* Converts signal event to I/O event. */
void sig_catcher(int signo)
{
    int err;
    
    /* Save errno to restore it after the write() */
    err = errno;
    /* write() is reentrant/async-safe */
    write(sig_pipe[1], &signo, sizeof(int));
    errno = err;
}

/* Signal processing function. */
/* This is the "main" function of the signal processing thread. */
void *sig_process(void *arg)
{
    st_netfd_t nfd;
    int signo;
    
    nfd = st_netfd_open(sig_pipe[0]);
    
    for ( ;; ) {
        /* Read the next signal from the pipe */
        st_read(nfd, &signo, sizeof(int), ST_UTIME_NO_TIMEOUT);
        
        /* Process signal synchronously */
        switch (signo) {
        case SIGHUP:
            /* do something here - reread config files, etc. */
            break;
        case SIGTERM:
            /* do something here - cleanup, etc. */
            break;
            /**
             * Other signals
             */
        }
    }
    
    return NULL;
}

int main(int argc, char *argv[])
{
    struct sigaction sa;
    ...
    
    /* Create signal pipe */
    pipe(sig_pipe);
    
    /* Create signal processing thread */
    st_thread_create(sig_process, NULL, 0, 0);
    
    /* Install sig_catcher() as a signal handler */
    sa.sa_handler = sig_catcher;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGHUP, &sa, NULL);
    
    sa.sa_handler = sig_catcher;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGTERM, &sa, NULL);
    ...
    
}

注意，如果使用了多个进程（看下面），信号管道应该在调用 fork(2) 之后进行初始化，以便每个进程都可以有自己的私有
管道。

3. 进程内同步

由于库 scheduler 的事件驱动特性，线程上下文切换（进程状态改变）只能在一组众所周知的库函数中发生。这个集合包含
一个线程可以阻塞的函数：I/O 函数（st_read(), st_write(), etc），sleep 函数（st_sleep()，etc），还有线程同步
函数（st_thread_join(), st_conf_wait()，etc）。因此，特定于进程的全局数据不需要被锁保护，因为线程不会在关键的部
分被重新调度（同一时刻只有一个线程可以访问相同的内存位置）。出于同样地原因，非线程安全的函数（在传统意义上）
可以被 State Threads 安全地使用。对于一个正确编写的应用程序（在关键部分没有阻塞函数），库的 mutex 实际上是没有
作用的，主要是为了提供完整性。锁的缺失极大的简化了应用程序的设计，并未可伸缩性提供了基础。

4. 进程间同步

State Threads 库可以将大量的并发连接转换成更少的单独进程，其中每个进程使用一个多对一的用户级线程实现（M:1 的 N
个映射而不是在某些平台上本地线程库使用的一个 M:N 的映射）。这种设计是应用程序可伸缩性的关键。可以这样想，好像
一组所有的线程都被划分为单独的组（进程），其中每个组都有一个单独的资源池（虚拟地址空间、文件描述符等）。应用程
序设计者完全控制应用程序创建的组（进程）的数量，以及通过标准 UNIX 进程间通信（IPC）在不同组间共享的资源。

创建多个进程有以下几个原因：

• 方便利用系统中可用的多个硬件实体（CPU、磁盘等）（硬件并行性）。
• 为了减少当一个进程崩溃时丢失大量的用户连接的风险。例如，如果 C 用户连接（线程）被复用到 P 进程中，其中一个进程
  崩溃了，那么所有的连接仅有一小部分（C/P）将丢失。
• 为了克服操作系统对每个进程资源的限制。例如，如果 select(2) 用于事件轮询，每个进程并发连接（线程）的数量受到
  FD_SETSIZE 参数的限制（参见 select(2)）。如果 FD_SETSIZE 等于 1024，每个连接需要一个文件描述符，那么应用
  程序应该创建 10 个进程来支持 10,000 个连接。

理想情况下，所有的用户会话都是完全独立的，因此不需要进程间通信。最好有几个独立的更小的特定于进程的资源（例如，
数据缓存），而不是所有进程共享一个大的资源。然而，有时需要在不同的进程间共享一个公共的资源。在这种情况下，可以
使用标准的 UNIX IPC。除此之外，还有一种方法可以同步不同的进程，这样只有当资源不可用时，访问共享资源的线程才会
被暂停（而不是整个进程）。在以下代码片段中，一个管道用作进程间同步的计数信号量：

#ifndef PIPE_BUF 
#define PIPE_BUF 512 /* POSIX */
#endif

/* Semaphore data structure */
typedef struct ipc_sem {
    st_netfd_t rdfd; /* read descriptor */
    st_netfd_t wrfd; /* write descriptor */
}ipc_sem_t;

/* Create and initialize the semaphore. Should be called before fork(2). */
/* 'value' must be less than PIPE_BUF. */
/* If 'value' is 1, the semaphore works as mutex. */
ipc_sem_t *ipc_sem_create(int value)
{
    ipc_sem_t *sem;
    int p[2];
    char b[PIPE_BUF];
    
    /* Error checking is omitted for clarity */
    sem = malloc(sizeof(ipc_sem_t));
    
    /* Create the pipe */
    pipe(p);
    sem->rdfd = st_netfd_open(p[0]);
    sem->wrfd = st_netfd_open(p[1]);
    
    /* Initalize the semaphore: put 'value' bytes into the pipe */
    write(p[1], b, value);
    
    return sem;
}

/* Try to decrement the "value" of the semaphore. */
/* If "value" is 0, the calling thread blocks on the semaphore. */
int ipc_sem_wait(ipc_sem_t *sem)
{
    char c;
    
    /* Read one byte from the pipe */
    if (st_read(sem->rdfd, &c, 1, ST_UTIME_NO_TIMEOUT) != 1)
        return -1;
    
    return 0;
}

/* Increment the "value" of the semaphore */
int ipc_sem_post(ipc_sem_t *sem)
{
    char c;
    
    if (st_write(sem->wrfd, &c, 1, ST_UTIME_NO_TIMEOUT) != 1)
        return -1;
    
    return 0;
}

通常，使用 State Threads 库编写应用程序的时候应该遵循以下步骤：

1. 初始化库（st_init()）。
2. 创建将要在不同进程间共享的资源：创建和绑定侦听套接字，创建共享内存段，IPC 通道，同步原语等。
3. 在每个子进程中创建一个线程池（st_thread_create()）来处理用户连接。

5. 非网络 I/O

State Threads 体系结构使用 st_netfd_t 对象上的非阻塞 I/O 来并发处理多个用户连接。这种体系结构有一个缺点：整个进程
及其所有线程可能会在磁盘或其他非网络 I/O 操作期间阻塞，无论是通过 State Threads I/O 函数，直接系统调用，或者标准
I/O 函数。（这主要适用于磁盘读；磁盘写通常是异步执行的 -- 数据先写入到 buffer 缓存，然后再被写入到磁盘。）辛运的
是，磁盘 I/O（不像网络 I/O）通常需要一个有限且可预测的时间，但对于特殊设备或用户输入设备（包括 stdin）可能不适
用。然而，这样的 I/O 减少了系统的吞吐量，并增加了响应时间。有几种方法可以设计一个应用程序来避免这种缺点：

• 如前所述，创建几个相同的主进程（对称架构）。这将提高 CPU 利用率，从而提高系统的总体吞吐量。
• 除了处理阻塞 I/O 操作的主进程（不对称体系结构）之外，还有创建多个 "helper" 进程。这个方法是由 Peter Druschel
  等人在一篇论文中提出的。在这个架构中，主进程通过 IPC 通道（pipe(2), socketpair(2)）与 "helper" 进程通信。主进程
  指示 "helper" 去执行潜在的阻塞操作。一旦操作完成，"helper" 将通过 IPC 返回通知。

6. 超时

st_cond_timedwait() 和 I/O 函数的超时参数是 st_sleep() 和 st_usleep() 自上一次上下文切换（而不是自上一次函数调用开始后）的最大时间。

State Threads 的时间分辨率实际上是上下文切换之间的时间间隔。在某些情况下，这个时间间隔可能很大，例如，当单个线程
连续执行大量工作时。注意，一个稳定的、不间断的网络 I/O 流符合这个描述；只有在线程阻塞时才会发生上下文切换。

如果指定的 I/O 超时小于上下文切换之间的时间间隔，则该函数可能会在函数开始调用后经过该时间量（指上下文切换的时间
间隔）之前返回超时错误。例如，如果自上一次上下文切换后已经过去了 8 ms，超时时间为 10 ms 的 I/O 函数可能会导致一
次切换，则在该函数调用后的 2 ms 返回一个超时错误（在 Linux 上，select() 的超时时间是 select() 返回前经过的时间的
上限）。同样，如果已经过去了 12 ms，函数可能立即返回。在几乎所有的情况下，I/O 超时应仅用于检测断开的网络连接或者
防止对方长时间保持空闲连接。因此，对于大多数应用程序来说，实际的 I/O 超时应该在几秒钟内。此外，重试超时操作可能
没有意义，也不要重试使用一个简单的更大的超时。

最大的有效超时值取决于平台，并且可能会显著的小于 select() 的 INT_MAX 秒 或 poll() 的 INT_MAX 毫秒。一般情况下，
你不应该使用超过几个小时的超时。使用 ST_UTIME_NO_TIMEOUT(-1) 作为一个特殊值来指示无限超时或者无限期休眠。使
用 ST_UTIME_NO_WAIT(0) 来指示不等待。