Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site amdahl.UUCP Path: utzoo!utcs!lsuc!pesnta!amdcad!amdahl!mat From: mat@amdahl.UUCP (Mike Taylor) Newsgroups: net.arch Subject: Re: Magic Cookies and File Systems (Religious FLAME) Message-ID: <1261@amdahl.UUCP> Date: Mon, 11-Mar-85 12:11:44 EST Article-I.D.: amdahl.1261 Posted: Mon Mar 11 12:11:44 1985 Date-Received: Mon, 11-Mar-85 22:24:38 EST References: <917@sjuvax.UUCP> <538@rlgvax.UUCP> <190@u1100s.UUCP> <1078@watdcsu.UUCP> Organization: Amdahl Corp, Sunnyvale CA Lines: 20 > 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. It's a small point, but the facts might as well be straight. Since RESERVE/RELEASE locks an entire volume, not a file, resulting in unwanted side-effects such as deadlocks, the internal named locks may be propagated through all sharing processors by a facility called Global Resource Serialization (GRS). GRS uses channel-to-channel connection to pass a token around all connected processors. Possession of the token allows tasks (processes) on that system to obtain/release global locks. The token is passed every n milliseconds (n = tunable parameter). -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]