_fread_nolock，_fseek_nolock的预期用途是什么？ [英] What's the intended use of _fread_nolock, _fseek_nolock?
问题描述
我们有一个C ++类，它基本上从二进制文件读取和写入向量。将单个向量加载到存储器中的示例性读取函数如下：
we have a C++ class which basically reads and writes vectors from a binary file. An exemplary read function that loads a single vector into memory looks like this:
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;}
$ b同时访问同一个文件。为了避免由于多线程的问题，我们总是在OpenMP关键语句中覆盖函数调用：
Out programs are multithreaded with OpenMP and multiple threads access the same file at the same time. To avoid issues because of multiple threads we always cover the function call within an OpenMP critical statement:
#pragma omp critical {
load(...);
}
我知道Microsoft Visual C ++运行时包含几个函数，如 _fseek_nolock ， _fread_nolock ， _fwrite_nolock 等等...例如 _fread_nolock（）函数描述为
I know that the Microsoft Visual C++ runtime contains several functions like _fseek_nolock, _fread_nolock, _fwrite_nolock and so on... For example the _fread_nolock() function is described as
此函数是一个非锁定版本恐惧。它与fread相同，除了它不受其他线程的干扰保护。它可能更快，因为它不会产生锁定其他线程的开销。仅在线程安全上下文（如单线程应用程序或调用作用域已处理线程隔离）中使用此函数。
This function is a non-locking version of fread. It is identical to fread except that it is not protected from interference by other threads. It might be faster because it does not incur the overhead of locking out other threads. Use this function only in thread-safe contexts such as single-threaded applications or where the calling scope already handles thread isolation.
问题：我理解，功能块重入调用，所以没有其他线程将在其他线程返回之前进入该函数。然而，我不明白为什么有必要以这种方式保护单个功能。 IMHO所有访问/修改文件指针（在代码示例中 _file ）的函数必须被保护，因此被设置为线程安全。这需要围绕整个函数块建立锁，从而实现调用标准C函数fseek和fread，因此我没有看到提供这种非阻塞函数的点。
Now my question: I understand that the function blocks "re-entrant" calls, so no other thread will enter the function before other threads have returned. However, I do not understand why it is necessary to protect a single function in that way. IMHO all functions that access/modify the file pointer (_file in the code sample) must be protected and therefore be made thread-safe. This requires to build a lock around the whole function block that actuall calls the standard C functions fseek and fread, so I do not see the point of providing such non-blocking functions.
有人可以向我解释这些锁定机制，因为我想我们的偏执型锁定方案会浪费一些性能？
Can someone explain me these locking mechanisms because I suppose our paranoid locking scheme wastes some performance?
谢谢
推荐答案
对于一些简单的代码，FILE *中的锁就足够了。考虑一个基本的日志基础结构，你希望所有线程通过一个共同的FILE *进行日志。内部锁将确保FILE *不会被多个线程损坏，并且因为每个日志行应该独立，所以个人调用交织无关紧要。
For some simple code, the lock within the FILE * is sufficient. Consider a basic logging infrastructure where you want all threads to log via a common FILE *. The internal lock will make sure the FILE * will not be corrupted by multiple threads and since each log line should stand alone, it doesn't matter how the individual calls interleave.
这篇关于_fread_nolock，_fseek_nolock的预期用途是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
