在C程序中打开与fopen（使用multithreading）

由于未知原因，似乎fopen在关闭之前重复调用文本文件时无法打开文本文件。

我的C程序使用multithreading，每个线程处理一种类型的输出文本文件（每种类型11个），每种类型都在一个单独的文件夹中。 我需要保留在长时间执行期间打开的这些文件以及在同一个线程中写入大量数据。

为了更好地解释它，过程如下：

1-线程＃1启动并在一个文件夹中创建和写入11个文件。

2-在不关闭以前的文件的情况下，线程＃2启动并创建并在另一个文件夹中写入另外11个文件。

3-与其他两个线程相同。

4-最后，当创建了所有需要的文件并且所有线程都已完成，除非是主文件，所有文件都被关闭。

然而令人惊讶的是，open能够同时处理所有这些文件。 有没有人对fopen的这个问题有一个提示？ 我不知道它是否与multithreading或fopen可以同时处理的最大文件数有关。

我在Borland编译器的Windows平台上。

Answer 1

这个问题不太可能与fopen 。 fopen使用open underneath，最大打开文件数可能与open相同。

我的猜测是你在其他地方有一个错误，很可能超出数组边界。

如果您没有使用任何Windows特定的function，您可以始终在Linux上进行valgrind 。

如果无法移植代码，则可以二进制搜索错误。 例如，注释掉写入文件的代码的一半，并查看问题是否仍然存在。 如果没有，问题可能在被注释掉的部分。 如果没有，问题出在没有评论的部分。

请注意上面的“可能”一词。 如果您的代码导致未定义的行为，则您不能依赖该行为。 即使是错误的代码也可以正常运行。

Answer 2

AFAIK f函数不是线程安全的。 open可能是fopen的基础，但在它下面所有的基本上都是（最初的Win32）函数CreateFile，ReadFile，WriteFile和CloseHandle。 它们是线程安全的，我建议你使用它们而不是在你的f-calls周围使用关键部分。

Answer 3

C Run Time（CRT）库是Windows XP及更高版本的线程安全。 此外，如果您认为CRT中的某些注释包含文件，则它有20个打开文件的限制。

所以，在你的申请中。 单个线程打开11个文件的原因是什么？ 通过同时编写它们，您不会获得可衡量的性能提升。 事实上，你可能会让它变得更糟，因为C盘会在试图写入每个文件时四处移动。

根据应用程序的设计方式：打开一个文件，写入文件直到完整，关闭它，打开第二个文件等。

现在，当每个线程尝试对同一个C驱动器进行I / O时，将磁盘颠簸的可能性乘以4！ 因此，如果可能，请序列化磁盘访问。 获得真正的改进增加缓冲区大小。