Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!tektronix!orca!paulsc From: paulsc@orca.TEK.COM (Paul Scherf) Newsgroups: comp.arch Subject: Re: H/W Write Buffers, S/W Synchronization Message-ID: <2420@orca.TEK.COM> Date: Fri, 30-Oct-87 13:24:54 EST Article-I.D.: orca.2420 Posted: Fri Oct 30 13:24:54 1987 Date-Received: Thu, 5-Nov-87 02:46:54 EST References: Reply-To: paulsc@orca.UUCP (Paul Scherf) Organization: Tektronix, Inc., Wilsonville, OR Lines: 24 Summary: It can be done without read-modify-write, but it is usually inefficient In article zs01+@andrew.cmu.edu (Zalman Stern) writes: >Seems to me that code like this already has to use an interlocked >read-modify-write cycle for the incrementing of the and > shared variables. Otherwise there are race conditions in the >code. Therefore my answer to question 1 is that code which accesses shared >variables without some sort of locking mechanism is broken. >I am not sure what restriction you are refering to in question 2. I think it >is impossible to write correct multi-threaded (asynchronous) code without >some kind of indivisible read-modify-write memory operation. I agree that indivisible read-modify-write memory operations are most often used for multiprocessor shared-memory syncronization. My point is that they are not required. There are software algorithms for this (e.g. Decker's algorithm. I may have mispelled the name). I am told that, in practice, software solutions have been very inefficient, so the read-modify-write cycle solutions are usually preferred. This is probably part of the reason why, as Zalman Stern points out, most modern processors have some sort of read-modify-write capability. Paul Scherf, Tektronix, Box 1000, MS 61-033, Wilsonville, OR, USA paulsc@orca.GWD.Tek.COM tektronix!orca!paulsc