Он просто резервирует диапазон файла для исключительного использования процесса, который получает блокировку файла. Если вызов блокировки завершается успешно, другой процесс, который пытается прочитать или записать эту часть файла, завершится неудачно. Это позволяет нескольким процессам обращаться к одному и тому же файлу и обновлять его согласованным образом. Это как мьютекс для диапазона файла.
По сути, это позволяет вам обновлять части файла атомарно, так что любой другой процесс, читающий или записывающий файл, увидит (или изменит) либо все обновление, либо ничего. Это также относится и к чтению - вы можете заблокировать диапазон файла, который вы хотите прочитать, чтобы предотвратить изменение части процесса другим процессом, пока вы находитесь в процессе чтения.
Но процессы по-прежнему могут обращаться к другим частям файла без ошибок или задержек.
Это не решит проблему в вопросе, на который вы ссылаетесь, потому что _lock()
on; t работает с гранулярностью процесса. Если поток A блокирует диапазон файлов, то поток B в том же процессе все еще может читать / записывать этот диапазон. Чтобы предотвратить доступ другого потока в том же процессе к диапазону файлов, процесс должен будет реализовать собственный внутренний механизм, обеспечивающий блокировку диапазона файлов другим потоком. По крайней мере, я ничего не знаю о том, что делает это в Win32 API (я полагаю, что может быть что-то, о чем я не знаю).