Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!nec-gw!netkeeper!news
From: koll@NECAM.tdd.sj.nec.com (Michael Goldman)
Newsgroups: comp.arch
Subject: Re: Microcomputer Bus Multiprocessing
Message-ID: <1991Mar22.185924.10593@sj.nec.com>
Date: 22 Mar 91 18:59:24 GMT
Sender: news@sj.nec.com
Organization: NEC-AM TDD, San Jose, California
Lines: 34
Nntp-Posting-Host: 131.241.12.43

The only experience I've had with multiprocessing and bus issues was in a
real-time system using 680x0 & Ready Systems' VRTX kernel and the related MPV
(MultiProcessor for for VME).  MPV uses a table in global memory to keep
track of where a CPU is and how to access it.  System calls (posts to queues,
semaphores, etc.) can be made across the bus by interrupting the addressed
CPU, (VME interrupt or mailbox interrupt) and passing a structure to the MPV
code on the 2nd CPU that contains the parameters necessary to make the system
call locally.  In this situation, even though all memory is global, it is shared
through semaphore-like arrangements, using the Motorola 68K TAS (test and set)
instruction.  One member of our team discovered an interesting problem with the
TAS instruction using cycle-by-cycle-interleaved memory access.  Although the
VME spec requires that the bus be locked during the multi-cycle TAS to insure
that TAS is an atomic operation, the local CPU bus did not.  Thus, we
occasionally had CPU-1's TAS interleave with CPU-2's TAS.
This worked as follows:

  CPU-1	   TEST (thinks lock open) SET (thinks it owns memory)
  
  CPU-2              TEST (thinks lock open) SET (thinks it owns memory)
  
  Memory     0         0            1         1      (trash)
  
The solution for us was to put the MPV tables on a separate memory-only
board.  I believe Software Components' pSOS+ MPV-equivalent approaches the
problem differently.

Radstone sells a VME board that has a 68040 and a 68020 on the same board.
They consider the 68020 as an I/O processor that fields all the interrupts
for Ethernet, SCSI, VMEbus, etc. with separate memory for each CPU.  One of the
proprietary Real-Time Unix companies did something similar to minimize interrupt
latency.

There was a lot of concern about bus-snooping in the Futurebus+ discussions
and I'm curious as to how it was resolved.