Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watdcsu.UUCP
Path: utzoo!watmath!watdcsu!herbie
From: herbie@watdcsu.UUCP (Herb Chong [DCS])
Newsgroups: net.arch
Subject: Re: Magic Cookies and File Systems (Religious FLAME)
Message-ID: <1078@watdcsu.UUCP>
Date: Wed, 6-Mar-85 20:27:29 EST
Article-I.D.: watdcsu.1078
Posted: Wed Mar  6 20:27:29 1985
Date-Received: Thu, 7-Mar-85 04:08:54 EST
References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <190@u1100s.UUCP>
Reply-To: herbie@watdcsu.UUCP (Herb Chong [DCS])
Organization: U of Waterloo
Lines: 95
Summary: 

In article <190@u1100s.UUCP> sjs@u1100s.UUCP (Stan Switzer) writes:
>On the contrary, all magic cookies should be tied to the file system in
>some way.  It really burns me the way some message passing, locking,
>and semaphore systems use a globally administered pool of names (or
>worse yet, numbers!!) for the names of entities.  The file system directory
>structure is the ONLY logical place for global names of ANY kind to reside.
and you pay for it too unless your entire file directory resides in
memory all the time, in which case you have consistency problems, not
to mention taking up real memory which could be allocated to other
things besides file names.  numbers are perfectly reasonable things to
have as names of entities.  are you going to read and make decisions
based upon these names?  no, a program is going to, and it is just as
happy with a short name(word) as a long one, but a long one takes up so
much more space.

>UNIX drew on this idea from MULTICS, and used it to good advantage.  As in
>MULTICS, devices and executable programs are just a particular kind of
>enrty in the file system.  In MULTICS it went further: memory, in fact
>everything, was named in the file system.
and look at how much overhead MULTICS has.  not that MULTICS is bad
conceptually, but why run a system that permanently takes away more
than half your CPU for overhead when you can run Unix, which is just
about as flexible most of the time, and you get one quarter or more of
your CPU back to boot.

>Actually I agree about locking resources, but locking ranges of bytes in
>files is useful too.  Anyway, for the purpose of locking resources, you
>just need a file (special or otherwise) to represent a resource, and you
>do your locking against that file.
locking bytes, or inability to do so, is as much a function of hardware
as software.  implementation that is both efficient in memory and time
requires some help from both.

>IF SOMETHING NEEDS A NAME, PUT IT IN THE FILE SYSTEM!!!!!!!!!!!!!!!
>
>--------------------------------------------------------------------------
>Stan Switzer     |  "We're gonna have a TV party tonight.
>ihnp4!u1100s!sjs |   Alright!"  -- Black Flag

there is something very fundamentally wrong here with stan's argument.
how do i ensure no two people have locked on the same file at the same
time?  no, you can't do an i/o to find out, because the other process
may be queued just ahead of you for the device so that a query finds it
unlocked, but the locking command (i/o or whatever) encounters an
already locked file.  but this is a dumb disk, it just goes ahead and
locks it anyway.  so now you have two processes with exclusive access
to the lock at the same time.  you can imagine what will happen when
both try to write to the file.  you have to check before you actually
lock in a manner that will guarantee exclusive access by one process so
what do you do?  you lock on a bit (word or whatever) in memory and
THEN lock on the file.  but why bother locking on the file when you
couldn't care less about the file but some other shared resource.  AH,
but a SMART disk drive would stop this.  big deal, the lock is still in
memory, but it's the device controller's now.  still not on disk.
now, let's give the bit a NAME, so it's not fixed to any one location
in storage.  need i go on?

for those of you who don't know, OS/360 (really MVS) has both internal
named locks (ENQ/DEQ) and file locks.  in a multiple processor
environment without shared memory, file locks are used because there is
really no other way.  the controller has the smarts to acknowledge a
RESERVE and prevent all I/O from any other CPU's to that device until
the CPU issuing the RESERVE is finished with it. (i might mention at
this point that a small MVS system will only have 30 or 40 disk devices
attached.)  when the processors share memory, the memory management
units serialize access to shared storage so that a locking technique
works with words (actually, double words) for all shared resources.
speed is of main concern here.  you do not want to tie up a shared
resource more than you have to when a typical i/o instruction can take
tens of thousands of CPU cycles and you need to do at least two to lock
on a file by setting bits in the filesystem.  why two?  one to issue
the lock, and another to see if you really got it.  if you don't have
to do the last one, then you're already got "magic cookies" that don't
use the file system.

there is a very pragmatic reason for using using named "magic cookies"
in a system for interprocess synchronization rather than the file
system.  it takes orders of magitudes less time and the system can
continue to schedule processes instead of waiting around for a lock to
be satisfied.  also, since the lock is in memory and never needs to be
updated to disk, consistency of the locks is ensured with much less
overhead.

this really belongs in net.flame or net.religion.operating-systems, but
i am putting it here since no-one else will pay attention otherwise.

Herb Chong...

I'm user-friendly -- I don't byte, I nybble....
(but i'm sick and tired of ignorance)

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA:  herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu