🚀 go-pugleaf

>|> In my synchronization survey I call this the "spinning on a
>|> non-running processor" problem.  So far, only the i860 has a general
>|> solution to this problem, with its operation that blocks interrupts
>|> for a short length of time from user mode.
>|> 
>
>BBN's latest Butterfly was designed with this feature, although I don't
>think it got used.  (Yes, I know they called it the TC-2000, not the
>Butterfly 2.  What do they know.)  Locking was done with xmem instead.

I have the TC2000 manuals, and I believe that I looked closely for any
feature that avoids the "spinning on a non-running processor" problem.
There does not seem to be any hardware support for this, although if I
have missed it I would be happy to be corrected.  If there is support
for the "spinning on a non-running processor" problem in the BBN
TC2000, I conjecture that it is purely in the OS in the form of
something like gang scheduling.

The TC2000 does have the ability to block interrupts, but not from
user mode. Again, correct me if I am wrong.

The TC2000 UNIX does provide a variety of atomic synchronization
primitives, like compare-and-swap, fetch-and-add, fetch-and-or, etc.
These are implemented as system calls. The system call blocks
interrupts, XMEM is used for the hardware lock that excludes other
processors, and the operation is performed.  
    I think that what we are all interested in is a way of doing these
forms of synchronization without system calls.

Spinlocks on the TC2000 must be test-and-set spinloops.  You can't
even use a cache test to do a test-and-test-and-set spinloop.  The
TC2000 manual goes into great detail about adding delays to a
test-and-set spinloop to reduce contention.



By the way - MIPS' load-locked/store-conditional synchronization
primitives might conceivably be used to block interrupts as well as
providing atomic interprocessor RMWs.
    Question for MIPS: are interrupts blocked inside a
load-locked/store-conditional sequence?
    Personal preference: it's better to separate the interrupt
blocking and the atomic RMW functionality.  



[*] thanks to someone at BBN - if you want the synchronization
features of your machine to be discussed in the December, 1991,
edition of the synchronization survey, tell me about it now. "Telling
me about it" can comprise email about the synchronization features,
although spec sheets, users manuals, etc. are always preferred (mainly
because half the things people have told me by email have been wrong).
Send to:

    My email address is glew@ichips.intel.com

    My office phone is 503-696-4119
    Office FAX: 503-648-7397

    My mail address is

	Andy Glew
	Mail stop JF1-19
	Intel Corporation
	5200 NE Elam Young Parkway
	Hillsboro, OR 97124-6497
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Parkway, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.