多线程下的fwrite和write

Linux下的文件操作，有人喜欢用C库的文件流操作，有人喜欢用Linux的原生的系统调用。一般来说，C库的文件操作会更高效一些，因为C库自己做了文件缓存的处理。今天，主要研究多线程下的fwrite与write，每个线程都对相同的FILE*或者fd进行写操作，看看结果是否为预期行为。

第一种情况：使用C库的fwrite，其线程的实现如下：

第二种情况：使用系统调用write，其线程的实现如下：

下面看主线程的实现：

其中LOOPS定义为1000000。也就是说，线程1~3分别写入"aaaaaa\n"，"bbbbbb\n"，和"cccccc\n"各一百万次。如果写入文件的操作是“线程安全”的，那么最终的文件行数应该是3百万行，且每行只可能是"aaaaaa"、"bbbbbb"、和"cccccc"的一种。

接下来看测试结果：

1. 定义了宏USE_CLIB，即使用C库的fwrite，其结果如下：

2. 注释掉红USE_CLIB，即直接使用系统调用write，其结果如下：

从上面的测试结果看，无论是C库的fwrite还是系统调用的write都可以保证输出不会混杂——即多线程的输出不会混在一起，但是使用系统调用write时，最终的文件行数是非预期的，远小于总数3百万行。也就证明了，write系统调用是非“线程安全”的。多线程下，其输出会互相覆盖。而C库的fwrite是线程安全的函数。

为什么结果是这样的？我们先看fwrite的实现，下面的代码来自与glibc的截图。

在fwrite内部，其使用一个lock保证操作的串行化，从而实现线程安全。

而write的实现，见下图：

在写入之前，使用file_pos_read拿到偏移。如果在多核多线程的情况下，两个核心可能同时陷入内核态，同时获得文件的当前偏移，其值必然是相等的。于是两个线程往同一个偏移写入了数据。最后导致文件的实际大小，并不是预期大小。

最后总结：C库的fwrite是线程安全函数，而系统调用write则需要额外的标志位O_APPEND做追加写，来保证偏移的不重叠，实现预期的并发写入 —— 大家可以通过修改下面的测试代码，在自己的环境中测试。

PS：

1. 完整的测试代码位于：https://github.com/gfreewind/LinuxDetails/blob/master/fs/5.multi_thread_write_file/multi_thread_write_file.c