NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/stratus/89

Internet Message Format | 1993-01-06 | 4.6 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!news.bbn.com!noc.near.net!transfer.stratus.com!transfer.stratus.com!usenet
From: [e-mail] (Dan Danz)
Newsgroups: comp.sys.stratus
Subject: Re: Shared Virtual Memory & mp_debug
Date: 7 Jan 1993 04:30:11 GMT
Organization: Stratus Computer Inc, Marlboro MA
Lines: 81
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: quiensabe.az.stratus.com

Tom M Moravansky writes
> A programmer I work with ran across something unusual yesterday.
> We are running VOS 11.5 on a Stratus.  He found that when an SVM
> lock word is displayed using mp_debug, the value of that word is
> set to hex 7fff.  This value causes the word to be locked.  The
> debugger never unlocks the word and it must be manually unlocked.
>
> Anyone else ever see this behavior?  Does it exist in older
> versions of VOS?

If a page of shared virtual memory is declared as a lock word region
then things like this begin to happen.  This is by design and is the way
that hardware locking works.

When a page is marked as a lock word region, the StrataBUS interface to the
memory treats ALL reads to the page as READ-MODIFY-WRITE cycles.  These
so-called interlock cycles are indivisible -- no other board can access the bus
during the time.

During the read phase, the original 16 bits of data at the given address are
fetched (and will be given to the requester of the memory fetch);  next, the
most significant bit is changed to 0; and finally the modified value is
rewritten to the physical memory location.

Now, using the convention that a lock word with the MSB SET is NOT locked and
one with the bit set IS locked,  it becomes very easy to implement locks to
protect critical sections of code or to prevent data in shared virtual memory
from being manipulated by more than one cpu at a time.

Initialize the lock word region so that any lock words in it contain a value
of minus one (0x7FFF).  Then, use the following algorithm whenever you need
to perform a critical section of code.

1.  Read the lock word as a 16-bit value.

2.  If the value you read has the most significant bit cleared (the value
    will be zero or positive if the lock word is regarded as a 16-bit
    signed integer), then some other entity owns the lock.
    Delay for a bit (to prevent hogging of the bus or the cpu) and
    then restart at step 1.

3.  If the value you get has the high bit set,  you just acquired
    the lock. However, the hardware cleared the high bit when it rewrote
    the lock word.  Thus any other cpu reading the locaction will find
    the high bit cleared (as in step 2 above).   Because of the interlocked
    access, and the fact that only one requester can use the bus at a time,
    only one requester will receive a value with the high bit set, even if
    both requests are made at exactly the same instant.

3.  Perform the critical section of code.

4.  Clear the lock by writing any value that has the most significant bit
    set in the 16-bit value.

Lock word access is set on a PAGE (4096 bytes) of memory at a time;  any area
of that page that is not used as lock words is not much good for anything else
because of the effects noted in the original post.    For example, if you wrote
-1 (0xFFFF) to the location in the program, and then examined it with the
debugger, the first display by the debugger would show -1, but the second
and all following displays would show 32767 (0x7FFF) until either the
programmer or the debugger wrote a value with the high bit set.

And if you want more information, consult the subroutine manual pages for
s$connect_vm_region.   Additional information about locking is in the
document (master_disk)>system>doc>spin_lock.doc, which should be consulted
if you intend to wait for the lock by spinning on the read of the lock word.

Why not use a test-and-set (TAS) instruction, you ask?  Well, one reason is
that system memory is accessed by I/O controllers as well as CPU's, and locks
are used to protect data areas accessed by both.  Even if the main CPU chip had
a TAS instruction, the CPU used in the early controllers (a Z80) had none, so
the capability for locking was designed into the StrataBUS interface.

And, now you know the rest of the story ....

--
L. W. "Dan" Danz         (WA5SKM) VOS Mail:  [e-mail]
Sr Consulting Software SE         NeXT Mail: [e-mail]
Customer Assistance Center        Voice Mail/Pager: [phone]
Telecommunications Division       Customer Service: [phone]
Stratus Computer, Inc. 4455 E. Camelback #115-A, Phoenix AZ 85018