On 14 July 2016 at 19:25, Alin Serdean <aserd...@cloudbasesolutions.com> wrote:
> > [Alin Gabriel Serdean: ] > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365203(v=vs.85).aspx > The part: > "If the same range is locked with an exclusive and a shared lock, two > unlock operations are necessary to unlock the region; the first unlock > operation unlocks the exclusive lock, the second unlock operation unlocks > the shared lock." > > > > I see. Thank you. (I am blind!). I wonder whether we actually need the > exclusive lock then? If what we need is just shared lock, why not just take > it in the beginning? Would it have been possible to open the file in write > mode if someone had taken the exclusive lock in the first place? > > > > [Alin Gabriel Serdean: ] No worries the MS documentation is not that easy > to follow or precise in certain scenarios J. > > The problem is “Locking a portion of a file for *shared access denies* *all > processes* *write access* to the specified region of the file, including > the process that first locks the region. All processes can read the locked > region.” > > “Locking a portion of a file for *exclusive access* * denies all other > processes both read and write* access to the specified region of the > file. Locking a region that goes beyond the current end-of-file position is > not an error.” > > I agree it doesn’t make any sense why a shared lock would block the owner > but probably they had reasons to implement it that way. > What I was trying to say was, we open the file in write mode. It wouldn't have been successful if someone else had taken a lock (exclusive or shared). Am I correct? If so, why take exclusive lock again to write? Just write the pid and then take shared lock. Would that cause problems? (I must be missing some subtlety here.) _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
