5

Looking for answer of this question I found function _locking(). There tells that it Locks or unlocks bytes of a file (actually I can't understand what does this sentence really mean). If someone have experience of using of this function, is it possible to use the function for solving problem described in first question?

Community
  • 1
  • 1
Mihran Hovsepyan
  • 10,810
  • 14
  • 61
  • 111

4 Answers4

1

Quoting the MSDN page you linked:

int _locking(
   int fd,
   int mode,
   long nbytes 
);

The _locking function locks or unlocks nbytes bytes of the file specified by fd. Locking bytes in a file prevents access to those bytes by other processes. All locking or unlocking begins at the current position of the file pointer and proceeds for the next nbytes bytes. It is possible to lock bytes past end of file.

orlp
  • 112,504
  • 36
  • 218
  • 315
  • Yes, I read this. But when I've tried it to lock a file, then I couldn't write to the file via ofstream in same process. So what does locking for bytes really mean? – Mihran Hovsepyan Jul 27 '11 at 11:37
1

It simply reserves a range of a file for the exclusive use of the process that acquires the file lock. If a lock call succeeds, another process that tries to read or write that portion of the file will fail. This allow multiple processes to access the same file and update it in a coherent manner. It's kind of like a mutex for a range of a file.

Basically it allows you to update portions of a file atomically, so any other process reading or writing the file will see (or change) either all of the update, or none of it. It also applies to read - you can lock a range of a file that you want to read to prevent another process from changing part of it while you're in the middle of reading it.

But processes can still access other parts of the file without error or delay.

It will not solve the problem in the question you're referring to because _lock() on;t works at a process granularity. If thread A locks a file range, then thread B in that same process can still read/write that range. To prevent another thread in the same process from accessing a file range, the process would have to implement its own internal mechanism for respecting that a file range has been locked by another thread. At least I'm unaware of something that does that in the Win32 API (I suppose there could be something that I don't know about).

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • This function locks the file form all writes, and makes it only readable form those bytes. the user can easily add a flag that is globe to have the threads check before entering the file. – Dennis Hayden Jul 27 '11 at 14:15
  • @Dennis: according to the docs, the lock prevents any access - read or write - to the range. I'd have to run some tests to prove if it did otherwise. And that makes sense as well, if process A is changing a record in the file, process B wouldn't want to read the record until the update is complete. – Michael Burr Jul 27 '11 at 14:30
  • @Dennis: also don't overestimate how easy it might be to 'add a flag'. If you want the inter-thread access checks to be granular to file ranges, you need to keep some sort of data structure that indicates which ranges are locked, and you need synchronization mechanisms (critical section objects or whatever) to manage access to that data structure. It's not as trivial as checking a flag. Also, you'd need to *explicitly add* access checks everywhere it's needed. If you don't do the check at all the right times, then thread B will access the range while thread A has it 'locked'. – Michael Burr Jul 27 '11 at 14:40
  • This is the whole point of my link to race condition. He will have the same problem with using this function. He will have to check to see if the file is locked if it's locked "wait". He can even have a problem of a deadlock or many other things. I'm understanding that he wants to lock and unlock a file. This only locks part and he will still have to do all the other work. But I guess I can be wrong so never mind. – Dennis Hayden Jul 27 '11 at 15:02
  • @Michael Burr thank you for your respond. But I don't see it works such way. When I'm locking a file using the function in _LK_NBLCK mode to lock all bytes of the file, then I can't even read from the file in same process (strerror is "Permission denied"). Maybe I'm doing something wrong, and should read from same fd which is passed to `_locking()` instead of opening file again? – Mihran Hovsepyan Jul 28 '11 at 08:17
0

http://msdn.microsoft.com/en-us/library/8054ew2f(v=vs.71).aspx

I found that this helps "fix" the problem Race condition!

The last person to write to a file wins. Say you only need to read the first half of a file no reason to lock the whole file.

So you take the file size in bytes pass it to this function then lock it down.

The function will returns a 0 if successful. A return value of –1 indicates failure, in which case errno is set to what the MSDN page tells you.

To answer your question

You can take the size of the file then lock it down but you will only be able to read form the file. you lock it into a kind of read mode only.

In the wiki of Race condition it tell you examples of how to lock a file by getting a 2nd process to check for a flag this may work in your case look into it.

Dennis Hayden
  • 184
  • 1
  • 5
  • 15
0

It prevents other processes from accessing that same part of the file.

user541686
  • 205,094
  • 128
  • 528
  • 886