Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!ut-sally!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!hplabs!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.arch Subject: Re: H/W Write Buffers, S/W Synchronization Message-ID: <845@winchester.UUCP> Date: Wed, 28-Oct-87 00:15:31 EST Article-I.D.: winchest.845 Posted: Wed Oct 28 00:15:31 1987 Date-Received: Sat, 31-Oct-87 02:43:43 EST References: <2280002@hpsal2.HP.COM> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 55 In article <2280002@hpsal2.HP.COM> viggy@hpsal2.HP.COM (Viggy Mokkarala) writes: > Hardware Write Buffers and Software Synchronization >I have been looking into a problem involving software synchronization >using shared variables in tightly coupled private cache multiprocessor >systems with hardware write buffers. ....disucssion.... >The question is not "how to synchronize with write buffers", but rather the >follwoing: > 1. How much code already uses this? > 2. Is it difficult to write software with such a restriction?, and > 3. Would it be appropriate to force software writers to identify shared > variables? >John Mashey, are you listening? Yes, but I can't really say too much on this. Existing MIPS boxes use write-thru caches with 4-deep write buffers, so the only time they have anything like this problem is when synchronizing with smart controller cards. In some cases, this requires a wbflush() routine that loops until the write-buffer is empty. This is often needed when you're writing to a control register, then expect to look at a status register that is not in the same word as the control register, so the normal read/write conflcit detection has no chance to synchronize it itself. I've never worked on a system that had the particular combination described. A few general principles seem to obtain though: 1) The further away you get from normal memory semantics, the more of a pain it is for software. Exactly how much pain can be stood depends on overall system design tradeoffs. It is absolutely clear that current trends in system design tend to make caches more visible to software than they used to be. 2) If only the kernel has to deal with such things, it's not too bad, if it can be carefully encapsulated. There are usually ways around it, like using uncached memory for locks, although that would place restrictions on where locks go (i.e., it becomes more expensive to get locks into existing data structures that want caching). 3) If you want user-level locks to be pleasant, more hardware support is likely to be needed. 3) In general, I'd rather have cache coherency thought about from day one and get the right mechanisms in there. Multiprocessors are hard enough to get right without having to do weird things. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086