Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!ucbvax!ARIZMIS.BITNET!JMS From: JMS@ARIZMIS.BITNET (Joel M Snyder) Newsgroups: mod.computers.vax Subject: RE: Critical Regions in VAX/VMS Message-ID: <8608100118.AA29195@ucbvax.Berkeley.EDU> Date: Sat, 9-Aug-86 13:46:00 EDT Article-I.D.: ucbvax.8608100118.AA29195 Posted: Sat Aug 9 13:46:00 1986 Date-Received: Sun, 10-Aug-86 03:48:19 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 102 Approved: info-vax@sri-kl.arpa Critical regions in VAX/VMS can be achieved by use of the lock system. Locks are actually an implementation of mutex that runs across a single processor or a whole VAX cluster. In fact, locks are what Digital uses to keep the cluster hanging together. Locks are named resources that may be requested ($ENQ system service), released ($DEQ system service) or inquired about ($GETLKI system service). A process requesting a lock, and having it granted at the access mode requested, is assured that the textbook rules regarding mutex were followed. For example, if you $ENQ a lock named LOCK_A at the 'exclusive access' mode, and if the system grants it to you, you can be assured that you are the only process in your current group to have that lock granted. All other requests ($ENQs) will wait until you release ($DEQ) that lock. Locks can also be used system wide, but that requires the SYSLCK (system lock) privilege. Locks can also have 16-byte value blocks associated with them, and thus can be used as a crude (although effective) method of interprocess communication. This could represent your variable x in the program you submitted. For more information on locks, look in the system services manual. Like timing services, they have their own chapter in the introduction, as well as the definitions of each service. Here is an example set of subroutines for locks: .TITLE MUTEX - enqueues and dequeues locks for ED1 program .IDENT /01A/ ; Externals .EXTERNAL ED1_INUSE ; Macro library calls $SSDEF $LCKDEF .macro errorck,?l1 blbs r0,l1 $exit_s code=r0 l1: .endm ; Read-Write data program section .PSECT MUTEX_RWDATA,RD,WRT,NOEXE LKSB: .BLKQ 1 RESLEN: .BLKL 1 RESPTR: .BLKL 1 .PSECT MUTEX_CODE,EXE,RD,NOWRT .entry ed1$acquire_mutex,^m movl 4(AP),reslen ; get descriptor block movl reslen,resptr ; length and address movl @reslen,reslen ; get the length addl #4,resptr ; get buffer pointer movl @resptr,resptr ; and address of buffer cmpw reslen,#31 ; see if a problem with length blequ length_ok ; ... if no problem, skip movw #31,reslen ; ... if too long, shorten length_ok: $enq_s - efn=#1,- ; use event flag 0 lkmode=#LCK$K_EXMODE,- ; lock at exclusive access lksb=LKSB,- ; address of lock status block flags=#LCK$M_NOQUEUE,- resnam=RESLEN ; name of resource to lock cmpl R0,#SS$_NOTQUEUED ; did we get it? beql no_lock ; no, sorry errorck ; check for other errors ret ; yes, return no_lock: pushl #ED1_INUSE ; file is in-use calls #1,G^LIB$SIGNAL ; signal, and end ret .entry ed1$release_mutex,^m $deq_s - lkid=LKSB+4 ; the lock id is in lock status block movl #SS$_NORMAL,R0 ret .end jms +-------------------------------+ | Joel M Snyder | BITNET: jms@arizmis.BITNET | Univ of Arizona Dep't of MIS | ArizoNET: MRSVAX::JMS | Tucson, Arizona 85721 | Pseudo-PhoneNET: (602) 621-2748 +-------------------------------+ (std. disclaimer in re: nobody taking anything I say seriously) --*> "Wherever you go ... there you are." -- Buckaroo Bonzai <*--