Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!eos!labrea!sri-unix!garth!walter
From: walter@garth.UUCP (Walter Bays)
Newsgroups: comp.lang.c
Subject: Re: Don't trust TAS
Message-ID: <614@garth.UUCP>
Date: 23 Apr 88 07:18:05 GMT
References: <7794@alice.UUCP> <48767@sun.uucp> <144@obie.UUCP> <2182@frog.UUCP> <2150@ubc-cs.UUCP>
Reply-To: walter@garth.UUCP (Walter Bays)
Organization: INTERGRAPH (APD) -- Palo Alto, CA
Lines: 28

>	john@frog.UUCP (John Woods, Software) writes:
>	I would be interested to know how one does multi-processor locking on a
>	SPARC, however (or other RISC processors).
>
In article <2150@ubc-cs.UUCP> pajari@grads.cs.ubc.ca (George Pajari) replies:
>
>I think that the M68000 provides hardware signals which *may* lock
>the bus *if* the hardware designer has done the bus interface properly,
> [Discussion of system in which TAS did not lock the bus.
> He fixed it in software.]
>As mentioned above one can implement mutual exclusion without
>hardware support (i.e. entirely in software)...a good survey of 
>the techniques is in Alan C. Shaw's book 'The Logical Design of 
>Operating Systems'.

Good point.  Not always necessary for RISC, though.  The Clipper has
a test-and-set instruction.  I would bet the HP Precision series has
a test-and-set, since they have standard multi-processor models.  I'd
think even the purest of RISC architects would implement it.  (Even though
it takes more than one clock cycle :-)  The main reason there are few
RISC multi-processors is probably that few people want to pay for them.
-- 
------------------------------------------------------------------------------
Any similarities between my opinions and those of the
person who signs my paychecks is purely coincidental.
E-Mail route: ...!pyramid!garth!walter
USPS: Intergraph APD, 2400 Geng Road, Palo Alto, California 94303
Phone: (415) 852-2384
------------------------------------------------------------------------------