Don't trust TAS

[George Pajari]

In article <2182 at frog.UUCP>, john at frog.UUCP (John Woods, Software) writes:

> That is why the
> 68000 has the TAS instruction; TAS does NOT release the bus between the
> read and the write cycle.

It's not necessarily so.

I think that the M68000 provides hardware signals which *may* lock
the bus *if* the hardware designer has done the bus interface properly,
but there is nothing about the TAS or the 68000 which requires the
bus interface to be done right.

I learned this the hard way when turning an IRIS 3000 workstation into
a multiprocessor by adding another M68020 board.  Critical section
bugs all over the place.  Pulled all of the TAS instructions and
implemented locking using a sequence of instructions which did not
depend on *any* bus locks or atomic operations.  Voila...no problems.

Moral of the story:  don't trust the hardware!

P.S. - Don't blame SGI necessarily...the second M68020 wasn't by SGI
	and it is still an open question which processor wasn't
	creating/respecting the bus lock.

> I would be interested to know how one does multi-processor locking on a
> SPARC, however (or other RISC processors).

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

As an aside, who says the hardware support for mutual exclusion *has* to 
be in the CPU?   There are some vendors of multiprocessor machines who
have incorporated special semaphore registers in hardware (on the bus,
apart from any CPU) which change state upon a read...i.e. they return a 
value and increment automatically...a RISC processor could use these 
registers to implement mutual exclusion.

George Pajari