more on file \"attributes\"

[M.J.Shannon]

> Mr. Campbell has one point, at least, which should not be ignored. UNIX is
> badly in need of some sort of semaphore structure for use between
> processes which do not know about each other.  Without this facility,
> it would be very difficult to write a library which could provide
> reliable record locking, which is one of the facilities he needed
> which is sorely lacking in current UNIX.  It seems to me, after admittedly
> very little thought, that one of two things is needed:
> 
> 	1) some sempahore facility which would have a namespace which
> 		would allow owner/group/world read/write priviledges.
> 		This would actually be generally useful, and current file
> 		primatives do not provide this facility in a resource
> 		efficient or reliable manner.

System V has just such a semaphore facility.  It also has shared memory and
messages to allow processes to bind themselves to each other and cooperate
even more closely.

> 	2) a block level lock on a file, either physical block or logical
> 		block, preferably physical.

System Vr2 (I'm almost certain) has advisory file locking.  I don't have the
documentation handy, but it may allow the user to specify file addresses to be
locked.  While this is not mandatory locking (i.e., no processes will block on
reads or writes due to a lock), cooperating processes can prevent themselves
from stepping on each other's data with these locks.

> The first facility, I believe, is to be greatly preferred.  Please,
> arguments about using pseudo devices or files in the file system or
> pipes/sockets/wombats-carrying-postcards don't wash.  These are
> neither resource efficient nor portable.  The semaphore facilities
> necessary are not hard to implement (I have done them myself on other
> systems), and would help a great deal in solving many problems of
> record access, which contrary to popular opinion in UNIX land
> constitutes a great deal of what is done out in the real business world.
> 
> To my knowledge, all of the database systems providing for reliable
> record access do this by circumnavigating UNIX, which seems to me to
> be a bit of a waste.
> 
> I enjoy using UNIX as a development environment, and I believe that
> 99% of its ideas are in theory right, but it has a few shortcomings.
> Others have noticed the process synchronization shortcomings.  Has
> anyone done anything about them?
> 
> Jon Shapiro
> Haverford College

Flame on (medium-well):

What?  That famous university-developed system doesn't support any IPC?  No
locks?  No semaphores?  No shared memory?  No messages?  Gee....  No!

AT&T: The Right Choice; System V: The Right UNIX* System.

* - UNIX is a trademark of AT&T.  It is *not* a trademark of the Regents of
	California.

Flame reduced to pilot light.
-- 
	Marty Shannon
UUCP:	ihnp4!eagle!mjs
Phone:	+1 201 522 6063

Warped people are throwbacks from the days of the United Federation of Planets.