This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Help on posix file lock semantics


At 20.08.01 13:18 , you wrote:
>On Sun, Aug 19, 2001 at 11:06:13PM +0200, Gunnar Andre Dalsnes wrote:
> > Issue 2:
> > Affects: Uniprocess, fcntl->F_SETLK->F_RDLCK/F_WRLCK/F_UNLCK
> > 
> > Both win32 and posix allow only one type of lock per byte of a file.
> > 
> > Win32 fails if any region overlap.
> > 
> > Posix upgrades a lock if a region overlap.
> > HELP! A lock can upgrade multiple overlapped regions of any type?
> > HELP! An unlock can unlock multiple overlapped regions of any type?
>
>      There will be at most one type of lock set for each byte in the
>      file. Before a successful return from an F_SETLK or an F_SETLKW
>      request when the calling process has previously existing locks on
>      bytes in the region specified by the request, the previous lock
>      type for each byte in the specified region will be replaced by the

And locks outside of upgraded regions are resized to fit and kept as standalone locks?

Example:
A file has write lock from off. 10 to 20 and read lock from off. 30 to 40.
A new read lock from off. 15 to 35 upgrades both existing overlapped regions.

Now we have three locks?
-write lock off. 10 to 15
-read lock off. 15 to 35
-read lock off. 35 to 40

Or maybe they merged? 
-write lock off. 10 to 15
-read lock off. 15 to 40

The reason i ask is that i want F_GETLK to behave correctly if called afterwards.

>      new lock type. As specified above under the descriptions of shared
>      locks and exclusive locks, an F_SETLK or an F_SETLKW request will
>      (respectively) fail or block when another process has existing
>      locks on bytes in the specified region and the type of any of those
>      locks conflicts with the type specified in the request.
>
>So basicly, yes.
>
>It seems here it's about the process too, and not the
>filedescriptor itself.
>
> > Issue 3:
> > Affects: Multiprocess, fcntl->F_GETLK
> > 
> > Win32 has no way of obtaining blocking locks.
> > 
> > Posix can obtaing blocking read locks or both.
> > HELP! How can readlocks be blocking if locks are upgradeable (uniprocess)?
> > There is no such thing as blocking read locks among multiple processes eighter!
> > All i can think of is blocking write locks among multiple processes.
>
>I'm a little confused by what you're all saying.
>
>If someone already holds an exclusive/write lock, and you try to
>get a read/shared lock, and used F_SETLKW, you will have to wait
>until that lock is gone, and you can get it.
>
>Same goes for getting any lock when someone already has an
>exclusive/write lock.
>
>Read locks can't block each other, but write locks block
>everything else.

Stupid me:-) I get it!
But one thing's for sure:
A lock of any type can't block any lock attempt from same process (because of upgrading), right?


>Kurt

Thanks for your help!

Gunnar



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]