由于未知原因，fopen在关闭前重复调用时似乎无法打开文本文件。
我的C程序使用多线程，每个线程处理一种类型的输出文本文件（每种类型11个），每个类型都在一个单独的文件夹中。我需要保留在长时间执行期间打开的这些文件，并在同一个线程中写入大量数据。
为了更好地解释它，过程如下：
1-线程＃1启动并在一个文件夹中创建和写入11个文件。
2-在不关闭以前的文件的情况下，线程＃2启动并创建并在另一个文件夹中写入另外11个文件。
3-与其他两个主题相同。
4-最后，当创建了所有需要的文件并且所有线程都已完成，除非是主文件，所有文件都被关闭。
然而令人惊讶的是，open能够同时处理所有这些文件。有没有人对fopen的这个问题有一个提示？我不知道它是否与多线程或fopen可以同时处理的最大文件数有关。
我在Borland编译器的Windows平台上。
答案 0 :(得分：1)
fopen问题不太可能发生。 fopen下方使用open，最大打开文件数可能与open具有相同的限制。
我的猜测是你在其他地方有一个错误，很可能超出数组边界。
如果您没有使用任何Windows特定功能，您可以在Linux上始终valgrind。
如果无法移植代码，则可以二进制搜索错误。例如，注释掉写入文件的代码的一半，并查看问题是否仍然存在。如果没有，则问题是可能在被注释掉的部分上。如果没有，问题出在没有评论的部分。
请注意上面的“可能”一词。如果您的代码导致未定义的行为，则您不能依赖该行为。即使是错误的代码也可以正常运行。
答案 1 :(得分：1)
AFAIK f函数不是线程安全的。 open可能是fopen的基础，但在它下面基本上都是（最初的Win32）函数CreateFile，ReadFile，WriteFile和CloseHandle。它们是线程安全的，我建议你使用它们而不是在你的f-calls周围使用关键部分。
答案 2 :(得分：1)
C运行时（CRT）库是Windows XP及更高版本的线程安全。此外，如果您认为CRT中的某些注释包含文件，则其限制为20个打开文件。
所以，在你的申请中。单个线程打开11个文件的原因是什么？通过同时编写它们，您不会获得可衡量的性能提升。实际上，你可能会让它变得更糟，因为C盘会在试图写入每个文件时四处移动。
取决于您的应用程序的设计方式：打开一个文件，写入它直到完全，关闭它，打开第二个文件等。
现在，当每个线程尝试对同一个C驱动器进行I / O时，将磁盘抖动的可能性乘以4！因此，如果可能，请序列化磁盘访问。获得真正的改进可以增加缓冲区大小。