Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Aug 1999 12:52:21 +0930
From:      Greg Lehey <grog@lemis.com>
To:        Biju Susmer <bee@wipinfo.soft.net>
Cc:        FreeBSD Hackers <hackers@FreeBSD.ORG>
Subject:   Re: Mandatory locking?
Message-ID:  <19990825125221.I83273@freebie.lemis.com>
In-Reply-To: <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com>; from Biju Susmer on Wed, Aug 25, 1999 at 08:31:23AM +0530
References:  <19990824214523.A11992@ppp18415.on.bellglobal.com> <000301beeea6$1ea898a0$88291fac@wipro.tcpn.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wednesday, 25 August 1999 at  8:31:23 +0530, Biju Susmer wrote:
> All the files under Tandem's NSK has mandatory locking. The file cannot be
> opened if another process has it opened. some thing like
>
>   * if the file is opened for reading, any one can open it for
>     reading but opening for writing gives error
>   * if the file is open for writing, it can't be opened for
>     read/write

This isn't locking, it's access exclusion.  It's also not correct for
NSK.  NSK's OPEN procedure allows the following possibilities:

  - shared access.  Any process can open the file unless another
    process has it opened with a different access.
  - exclusive access.  Only this process can open the file.  If it's
    already open, the open call will fail.
  - protected access.  Only this process can have the file open for
    write.  If it's already open for writing, the open call will fail.

NSK uses the procedures LOCKFILE and LOCKREC for locking.  Like most
operating systems, locks are in the kernel and mandatory.

>   * if the process holding the file is killed, the lock is gone
>   * it is possible to get the pid of the process(es) which has
>     a given file open (like which process has file "xyz" open?
>     kind of query). btw, is there any way to get this info now in FBSD?

fstat or lsof.

> Also, file need not be explicitly locked. Opening a file puts proper
> lock.

I'm not sure what you're saying here.  Opening a file doesn't lock it.
If the file is audited, you must issue a BEGINTRANSACTION call before
you can access it, and TMF will place locks where necessary.

> A file which is open can't be deleted also ;)

That's because of NSK's simplistic file system.

> This kind of locking will solve most of the problems which are
> pointed out.  Mandatory locking on a part of the file is in no way
> better than advisory locking.

Again, I'm not sure how much of this you understand.  I was thinking
of doing something like NSK's LOCKREC function.

> All the files need not have this option. there must be a way to
> specify that "this file needs mandatory locking" to the kernel.

That's a point for discussion.

> I don't know what all changes are needed in the kernel.. but I'm
> thinking about dup() and fork().. What is the fate of the lock if
> the process does a fork()?

I can think of a number of scenarios.  Certainly another point for
discussion.

Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?19990825125221.I83273>