From owner-freebsd-arch Mon Oct 16 18:22:21 2000 Delivered-To: freebsd-arch@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id E55F037B484 for ; Mon, 16 Oct 2000 18:22:12 -0700 (PDT) Received: by border.alcanet.com.au id <115206>; Tue, 17 Oct 2000 12:21:51 +1000 Content-return: prohibited Date: Tue, 17 Oct 2000 12:21:50 +1100 From: Peter Jeremy Subject: Re: we need atomic_t To: Terry Lambert Cc: freebsd-arch@freebsd.org Mail-followup-to: Terry Lambert , freebsd-arch@freebsd.org Message-Id: <00Oct17.122151est.115206@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Apologies if this is a duplicate, I haven't seen the first copy come back via the mailing list] On Fri, Oct 13, 2000 at 02:19:20AM +0000, Terry Lambert wrote: >[ ... atomic_t ... ] > >> My unspoken minimum precision was going to be 24 bits, for situations >> where that wasn't enough the idea was to provide a atomic64_t, but >> only if the demand was reasonable. > >How would you handle this type on 386, 486, and Pentium machines, >if somone used it in code? The Pentium and later CPUs have a compare-double-and-swap. This could be used inside a loop to produce atomic operations on 64-bit objects (much the same as the Alpha atomic routines). The basic code sequence is: atomic_op64: movl mem,%eax movl mem+4,%edx loop: op_q {%ecx:%ebx} = {%edx:%eax} op {operand} lock cmpxchg8b mem jne loop Sticking the whole thing inside di/ei reduces the load/store window, but may or may not be necessary. Adding a spin count might also be worthwhile. It isn't possible to have atomic 64-bit operations on 386 or 486, but there was a previous agreement that FreeBSD wouldn't support SMP on either of these CPU's either. Since (AFAIK) no bus-master peripherals would need atomic 64-bit operations, protecting it with a disable/enable interrupts block should be adequate. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message