Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!daver!ditka!zinn!decvax.dec.com!abyss.zk3.dec.com!kenton
From: kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG)
Newsgroups: comp.arch
Subject: Re: Living With Old Baggage
Keywords: 68040 CAS2
Message-ID: <1991Apr22.175410.9840@decvax.dec.com>
Date: 22 Apr 91 17:54:10 GMT
References: <336@scorpio.gtephx.UUCP> <12741@pt.cs.cmu.edu> <14628@encore.Encore.COM>
Sender: usenet@decvax.dec.com (Usenet News System)
Reply-To: kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG)
Organization: Digital Equipment Corporation - Nashua, NH
Lines: 24
Nntp-Posting-Host: abyss.zk3.dec.com

In article <14628@encore.Encore.COM>, jcallen@Encore.COM (Jerry Callen) writes:

|> 
|> Yes, this is VERY complex by RISC standards, but it makes a number of
|> nasty synchronization problems almost trivially easy. You can sorta-kinda
|> emulate compare and swap using test and set (which the 88K has) and spin
|> locks, but to do so in complete safety you have to disable interrupts
|> (nasty from user code...).
|> 
|> -- Jerry Callen
|>    jcallen@encore.com

The 88K has xmem, not test and set, which is guaranteed to be an atomic
operation (the bus is locked between the read and write cycles).  This
can be used to create locks or compare and swap without disabling itnerrupts.

Go look at the locking primitives in Encore's 88K kernel.  They are built
around xmem's. (I was there.)


-----------------------------------------------------------------------------
==	jeff kenton		Consulting at kenton@decvax.dec.com        ==
==	(617) 894-4508			(603) 881-0011			   ==
-----------------------------------------------------------------------------