Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!crowl From: crowl@rochester.UUCP Newsgroups: comp.arch Subject: Re: H/W Write Buffers, S/W Synchronization Message-ID: <3656@sol.ARPA> Date: Wed, 28-Oct-87 08:38:35 EST Article-I.D.: sol.3656 Posted: Wed Oct 28 08:38:35 1987 Date-Received: Sat, 31-Oct-87 04:16:06 EST References: Reply-To: crowl@cs.rochester.edu (Lawrence Crowl) Organization: U of Rochester, CS Dept, Rochester, NY Lines: 40 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. The original poster did not indicate whether there was a single slave process or multiple slave processes. If there is a single slave process, then each of the counter variables is modified by only one process and the protocol will work without read-modify-write (assuming values are indeed propogated). There are many concurrent algorithms for which certain variables may only be modified by one process at a time, so the absence of a locking mechanism does not imply broken code. >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. It is possible, I have done it. As above, you must insure that only one process may ever modify a variable at a time. >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. It is appropriate to dynamically indentify shared variables, but it is not appropriate to statically identify shared variables. Putting my locking bits off in a special memory discourages me from coding highly concurrent data structures. -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627