c++ - What level are fread thread locks on? What level do they need to be on? -

visual studio's fread "locks out other threads." there alternate version _fread_nolock, reads "without locking other threads", should used "in thread-safe contexts such single-threaded applications or calling scope handles thread isolation."

even after reading other relevant discussions on two, i'm confused if locking fread implements on specific file struct, specific actual file, or on fread calls on totally different files.

if use nolock versions, level of locking need provide? can multiple threads in parallel reading separate files without locking? can multiple threads in parallel writing separate files without locking? or there global or static variables involved corrupted?

so, using nolock versions, able potentially achieve better i/o throughput (if aren't needlessly moving heads, reading off separate drives, or ssd drive), or potential gain reducing redundant locks single lock (which should negligible.)

does vs' ifstream.read function work regular fread? (i don't see nolock version of it.)

the ms standard library implementation supports multi-threading. c++ standard explain requirement:

27.2.3: concurrent access stream object, stream buffer object, or c library stream multiple threads may result in data race unless otherwise specified.

if 1 thread makes library call writes value stream and, result, thread reads value stream through library call b such not result in data race, a’s write synchronizes b’s read.

this means if write on stream, locking (not file locking, concurrent access locking in-memory stream data structure) done, sure concurrency manageged other threads using same stream.

this locking overhead there, if not needed. have performance aspect, according microsoft:

the performance of multithreaded libraries has been improved , close performance of now-eliminated single-threaded libraries. situations when higher performance required, there several new features.

this why _nolock functions provided. access stream directly without thread locking. must used extreme care, example:

• if application single threaded (another process using same stream has own data structure, , os manageds concurrency here)
• if you're sure no 2 threads use same stream (for example if have 1 reader thread , writing done outside porgramme).
• if have other synchronisation mechasnism protect critical section of code. example, if use mutex lock, or thread safe non blocking algorithm makes use of atomics.

in such cases, additional lock stream access not needed/redundant. file intensive functions, worth using no_lock then.

note: you've pointed out: it's worth using nolock intensive file accesses make millions of accesses.