3 ms·

Good article. I don't quite understand this part, though: Still not convinced [that you shouldn't use mandatory locking]? Man, you really must like punishment.

Good article. I don't quite understand this part, though: Still not convinced [that you shouldn't use mandatory locking]? Man, you really must like punishment. Look, imagine someone is holding a mandatory lock on a file, so you try to read() from it and get blocked. Then he releases his lock, and your read() finishes, but some other guy reacquires the lock. You fiddle with your block, modify it, and try to write() it back, but you get held up for a bit, because the guy holding the lock isn't done yet. He does his own write() to that section of the file, and releases his lock, so your write() promptly resumes and overwrites what he just did. If you're going to read some data and then potentially write modified data back over what you just read, shouldn't the first step before you even read it be to get a lock on the file or that range? Or, if your calculation might take a long time, at least get a lock right before you write it back, verifying first that you're writing over data that hasn't changed while you were off calculating?

stingraycharles 16y ago
That was my first intuition too. It sounds like a classic race condition, in which case you would simply acquire the highest level of locking (exclusive) before reading the data, to make sure all your accesses to the shared data are synchronized. But I'm pretty sure I'm misunderstanding what the author was trying to say.
- IgorPartola 16y ago
  He is talking about mandatory locks, where if I lock the file and do things properly, you cannot do operations on it, even if you disregard the locks. In other words, it's a "convenience": I can structure my program in such a way as to "guarantee" that I will have the exclusive lock on the file and even your "buggy" code won't be able to overwrite it despite the fact that your code does not acquire any locks. Seems like the perfect solution, until the madness described in the OP ensues. Also, mandatory locks are used in Windows. Ever try to delete that virus.exe while it's still running? Yeah.
  - deleted 16y ago
    [deleted]
  - glhaynes 16y ago
    I think I understand that, but it's still not clear to me how the type of the lock is the cause of the problem: the problem as far as I can see it is that the hypothetical programmer isn't acquiring a lock (regardless of type) before starting their operation and then holding it until completion. Mandatory locking certainly has its issues/annoyances, but in terms of the situation I quoted, if used properly [1], it works fine and there is no risk of unexpected results due to races. [1] acquire lock for maximum level of operations you might need and hold it all the way through to completion, or to avoid holding a lock on the object for too long, get and release multiple locks verifying as needed that the data hasn't changed each time
    - tedunangst 16y ago
      Mandatory locks lead people to believe that they are safe. Advisory locks come with no implicit promises, so people know that they only protect against well behaved apps (generally other instances of the same program) and adjust program behavior accordingly.

stingraycharles 16y ago

That was my first intuition too. It sounds like a classic race condition, in which case you would simply acquire the highest level of locking (exclusive) before reading the data, to make sure all your accesses to the shared data are synchronized. But I'm pretty sure I'm misunderstanding what the author was trying to say.

IgorPartola 16y ago
He is talking about mandatory locks, where if I lock the file and do things properly, you cannot do operations on it, even if you disregard the locks. In other words, it's a "convenience": I can structure my program in such a way as to "guarantee" that I will have the exclusive lock on the file and even your "buggy" code won't be able to overwrite it despite the fact that your code does not acquire any locks. Seems like the perfect solution, until the madness described in the OP ensues. Also, mandatory locks are used in Windows. Ever try to delete that virus.exe while it's still running? Yeah.
- deleted 16y ago
  [deleted]
- glhaynes 16y ago
  I think I understand that, but it's still not clear to me how the type of the lock is the cause of the problem: the problem as far as I can see it is that the hypothetical programmer isn't acquiring a lock (regardless of type) before starting their operation and then holding it until completion. Mandatory locking certainly has its issues/annoyances, but in terms of the situation I quoted, if used properly [1], it works fine and there is no risk of unexpected results due to races. [1] acquire lock for maximum level of operations you might need and hold it all the way through to completion, or to avoid holding a lock on the object for too long, get and release multiple locks verifying as needed that the data hasn't changed each time
  - tedunangst 16y ago
    Mandatory locks lead people to believe that they are safe. Advisory locks come with no implicit promises, so people know that they only protect against well behaved apps (generally other instances of the same program) and adjust program behavior accordingly.