Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!littlei!intelisc!ichips!ichips!glew
From: glew@pdx007.intel.com (Andy Glew)
Newsgroups: comp.arch
Subject: Re: Microcomputer Bus Multiprocessing
Message-ID: <GLEW.91Mar22132302@pdx007.intel.com>
Date: 22 Mar 91 21:23:02 GMT
References: <1991Mar22.185924.10593@sj.nec.com>
Sender: news@omews63.intel.com (News Account)
Organization: Intel Corp., Hillsboro, Oregon
Lines: 32
In-Reply-To: koll@NECAM.tdd.sj.nec.com's message of 22 Mar 91 18:59:24 GMT


    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 is exactly the sort of cautionary tale I put in my "Survey of
Synchronization Primitive Implementations".   

Michael - can you give me more details (like company name) or does
that violate non-disclosure agreements?

Other readers - if you have any other real-life examples of problems
with synchronization primitive implementations, please send them to
me.


Reminiscing - this is the sort of thing that got me interested in computer
systems architecture in the first place.


--
---

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Parkway, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.