Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!PT.CS.CMU.EDU!andrew.cmu.edu!zs01+ From: zs01+@andrew.cmu.edu.UUCP Newsgroups: comp.arch Subject: Re: H/W Write Buffers, S/W Synchronization Message-ID: Date: Wed, 28-Oct-87 04:34:49 EST Article-I.D.: andrew.QVVPcty00Vs8yy40q5 Posted: Wed Oct 28 04:34:49 1987 Date-Received: Sat, 31-Oct-87 01:38:16 EST Organization: Carnegie Mellon University Lines: 22 In-Reply-To: <2280002@hpsal2.HP.COM> 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. Most modern processors offer at least a test-and-set instruction which implements a single bit semaphore. Some processors offer larger granularity locking mechanisms (i.e. the lock bit in the AMD 29000). Corect code will use one of these mechanisms to access shared variables. In any event, these instructions are already identifying shared variable accesses to the memory subsystem. So my answer to question number 3 is that it is entirely appropriate to require code to identify shared variables. Sincerely, Zalman Stern Internet: zs01+@andrew.cmu.edu Usenet: ...seismo!andrew.cmu.edu!zs01+ Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890