From owner-freebsd-hackers Thu Nov 14 09:44:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA20976 for hackers-outgoing; Thu, 14 Nov 1996 09:44:51 -0800 (PST) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA20924 for ; Thu, 14 Nov 1996 09:44:32 -0800 (PST) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.6/8.7.3) with ESMTP id JAA08935; Thu, 14 Nov 1996 09:44:10 -0800 (PST) Message-Id: <199611141744.JAA08935@austin.polstra.com> To: michaelh@cet.co.jp Subject: Re: Programming technique for non-forking servers? Newsgroups: polstra.freebsd.hackers In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Date: Thu, 14 Nov 1996 09:44:10 -0800 From: John Polstra 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 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. -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Self-knowledge is always bad news." -- John Barth