🚀 go-pugleaf

In article <GLEW.91May17100952@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>>|> 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.
>
>The TC2000 does have the ability to block interrupts, but not from
>user mode. Again, correct me if I am wrong.

At one time it was thought that the TC2000 could give the user the option of
blocking out interrupts via something called a user augmentations register
available in user space.  This turned out to not work well enough for O/S
related reasons.

Instead, the way we currently deal with the problem is to not worry about
the interrupts themselves.  They are not going to cause user mode locks any
problems since no interrupt code is ever going to take a user lock.  The
real problem, as stated before, is getting context switched as a result of
an interrupt (e.g. a scheduler interrupt).  To solve this, we provide
various system calls for the user to disable preemption.  Look at
user_nopreempt(2).  This allows XMEM based locks to avoid the "spinning on a
non-running processor" problem.

>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.

This is not exactly correct.  System calls are used for these atomic
operations, but they are of the "fast trap" kind where no context is saved
and no interrupts or other exceptions are handled during the call.  Each
operation is fairly short so this works well.  Also, XMEMs are NOT used to
implement any of these operations.  The TC2000 hardware has true locking
semantics on its memories and interconnection network.  This works by
locking a memory when a locked operation starts, and keeping it locked until
the entire operation is complete.  These are activated automatically by a
user mode XMEM and manually in the kernel to do the other atomic operations.
The general sequence for a fetch and op is:

Do preparatory work like checking that the memory is resident
Disable interrupts
Set lock bit (lock not taken until next real memory reference)
Read location (sets lock)
Operate on data in registers
Write result
Clear locks
Return original value

More details of the locking protocol are available in
"Inside the TC2000".

>    I think that what we are all interested in is a way of doing these
>forms of synchronization without system calls.
True enough.

#include <std_disclaimer>
_______________________________________________________________________________
				 ____ \ / ____
Laurence S. Kaplan		|    \ 0 /    |		BBN Advanced Computers
lkaplan@bbn.com			 \____|||____/		70 Fawcett St.
(617) 873-2431			  /__/ | \__\		Cambridge, MA  02238