_fread_nolock，_fseek_nolock的目的是什么？

Question

我们有一个C++类，它基本上是从二进制文件中读取和写入向量。将单个向量加载到内存中的示例性读取函数如下所示：

int load (const __int64 index, T* values) const {

 int re = _fseeki64(_file, index * _vectorSize + _offsetData, SEEK_SET); 
 assert(re == 0);

 size_t read = fread(values, sizeof(T), _vectorElements, _file);
 assert(read == _vectorElements);

 return 0;}

Out程序使用OpenMP多线程，多个线程同时访问同一个文件。为了避免出现多个线程问题，我们总是在OpenMP关键语句中讨论函数调用：

#pragma omp critical {
    load(...);
}

我知道MicrosoftVisualC++运行时包含一些函数，如_fseek_nolock、_fread_nolock、_fwrite_nolock等.例如，_fread_nolock()函数被描述为

这个函数是fread的非锁定版本.它与fread相同，只是它不受其他线程的干扰。它可能会更快，因为它不会导致锁定其他线程的开销。仅在线程安全上下文(如单线程应用程序)或调用作用域已经处理线程隔离的情况下使用此函数。

现在我的问题是:我理解函数阻止“可重入者”调用，因此在其他线程返回之前，没有其他线程将进入函数。然而，我不明白为何有必要以这种方式保护单一的职能。所有访问/修改文件指针的函数(代码示例中的_file)都必须受到保护，因此线程是安全的。这需要在整个函数块周围构建一个锁，这个函数块实际上调用了标准的C函数point和fread，所以我不认为提供这种非阻塞函数的意义。

有人能解释一下这些锁定机制吗?因为我想我们的偏执狂锁定计划浪费了一些性能？

提前谢谢你！

Answer 1

对于一些简单的代码，文件*中的锁就足够了。考虑一个基本的日志基础结构，您希望所有线程都通过一个公共文件进行日志记录。内部锁将确保文件*不会被多个线程破坏，而且由于每个日志行都应该是独立的，所以各个调用如何交织并不重要。

Answer 2

如果您使用Microsoft多线程C运行时，所有需要全局或静态变量的函数都会正常工作(例如printf和fread，但不要问我为什么它们需要全局变量)。但是，您仍然不能将文件*结构传递给写入它并期望它是线程安全的函数。

因此，微软的“线程安全”功能只有在它们是可重入的意义上才是线程安全的，即所有对全局和静态的访问都是用互斥或类似的方式完成的。但这并不意味着您可以使用同一个文件同时调用两个fprintf()。

来源：http://msdn.microsoft.com/en-us/library/1bh5ewb2%28VS.71%29.aspx

Answer 3

如果您的应用程序已经掌握了对文件句柄的序列化访问，那么如果告诉c-运行时绕过它自己的序列化，则可以获得更好的性能。这就是_fread_nolock等功能的目的。