From owner-freebsd-hackers Fri Nov 15 08:42:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27925 for hackers-outgoing; Fri, 15 Nov 1996 08:42:14 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA27910 for ; Fri, 15 Nov 1996 08:41:58 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id DAA18603; Sat, 16 Nov 1996 03:36:41 +1100 Date: Sat, 16 Nov 1996 03:36:41 +1100 From: Bruce Evans Message-Id: <199611151636.DAA18603@godzilla.zeta.org.au> To: jdp@polstra.com, michaelh@cet.co.jp Subject: Re: Programming technique for non-forking servers? Cc: hackers@FreeBSD.ORG Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> mset and mclear would be implemented as lib functions because Intel does >> have an atomic test and set. > >Yes it does: the "xchg" instruction. Load 1 into a register, then "xchg" >the register with the memory location containing the lock. Look at the >new value of the register to find out whether the lock was already >locked. It also has many other instructions suitable for locking primitives: bt, btc, btr, bts (386 up) sal (386 up) (standard trick) cmpxchg (486 up) xadd (486 up) cmpxchg8b (Pentium (up?)) >It even works in a multiprocessor system. According to the >Intel book: > If a memory operand is involved, the LOCK# signal is asserted for the > duration of the exchange, regardless of the presence or absence of the > LOCK prefix or of the value of the IOPL. I think the other instructions work in multiprocessor systems if they have a `lock' prefix. The optional locking makes them more useful on uniprocessors (actually, except for `sal' they are usually too slow to be worth using except for locking. E.g., on Pentiums `bt' of a memory variable takes 26 times as long as a simple instruction). Bruce