Results of Locking Poll

[Hokey]

Early in June I sent out a poll on the net to ask people what they wanted
in the way of file and/or record locking for Unix.  I received about 25
responses before I had to leave for Wherever the conference was, which
was also the site of a /usr/group Standards meeteing.

I apologize for the delay in posting the results of my study; the effort
was so frustrating that I get quite pissed off every time I think about it.
Anybody who has heard me pitch for mod.std.{c,mumps,unix} will probably
understand why I feel the use of these groups is so important.

Anyway, here we go:

1) Do you ever need a mutual exclusion mechanism?
	This was a trick question.  Everybody who replied said yes.
	Some suggested differentiating between semaphores and database
	locking.  They are right, but the same tool can *occasionally*
	be used for either purpose.

2) Do you prefer file or record locking?  Why?
	12 said File locking,
	 3 said Record locking,
	 3 said either, and
	13 said both, although most said file locks were usually sufficient.

3) Do you ever need (logical) transaction locks instead of a "simple"
file lock?
	17 said Yes
	 3 said No
	11 didn't know what I meant.

	Transaction locks can be thought of as "logical" locks, in that
	they apply over several files.  For example, a logical lock on
	"login" files would cover both /etc/passwd and /etc/group.
	Specifically, a logical lock encompasses all files which are
	part of the current "transaction".  They can be advisory or
	compulsory.  Advisory is fine in a controlled environment.

4) Do you wish to be able to have shared read locks as well as exclusive
write locks, or is "exclusive lock or no lock" sufficient?  Why?
	 2 said "All or nothing".  One of these said they only used
	  them for hardware devices, in any event.
	27 said they wanted shared/exclusive locks.  One said semaphores
	  was the answer for them.
	 2 didn't understand the question (their answers made no sense to me)

5) Do you ever do any recursive file operations in which a third type
of lock: shared read with option to convert to exclusive write?  This
lock is useful in multiway tree insertion or deletion, where node changes
might propagate up the tree to the root, but there is no need to prohibit
shared read access to the node until it is necessary to have exclusive
access to it in order to change its contents.
	19 said Yes,
	 4 said no, and they never would want it,
	 7 said no, but they might want it later, maybe.

That is it.  After I stripped out useless header info, the file containing
these replies is over 60Kbytes in length.  That's about 2K per respondent!

I told the /usr/group committee the results of this study, and the response
was "Too late.  They should have said so earlier.  We already printed the
draft standards and the votes are coming in.  We don't want to change it."
John Bass tells me that shared reads are hard to do under the currently
proposed lockf mechanism (1 process per "area" in the file.  This "area"
can extend to EOF.).  I don't yet see how this is difficult, but John
hasn't told me what the problem is.  Note that this mechanism provides
only all-or-nothing locks, as opposed to shared/exclusive access,
the one point where almost everybody who responded said they wanted
shared/exclusive access.

Please use the mod.std groups.  They are a much better way to make your
voice heard than hoping Somebody who reads net.unix or net.lang.c will
take your idea and run with it.  We all have to live with the results.
-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492