From owner-freebsd-hackers Fri Jan 31 06:45:28 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id GAA25305 for hackers-outgoing; Fri, 31 Jan 1997 06:45:28 -0800 (PST) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA25300 for ; Fri, 31 Jan 1997 06:45:25 -0800 (PST) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id JAA16465; Fri, 31 Jan 1997 09:43:52 -0500 Date: Fri, 31 Jan 1997 09:43:51 -0500 (EST) From: "Ron G. Minnich" X-Sender: rminnich@terra To: Andrew.Gordon@net-tel.co.uk cc: freebsd-hackers@freebsd.org Subject: Re: Re(2): Using rfork() / threads In-Reply-To: <"40b1-970131030103-8AD9*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well, i have another thing that was (ah well) offered to freebsd called fastlock(). Fastlock was two things: 1) test and set, which ran at memory bandwidth 2) a system call to be called only if the lock failed, which ran at system call speeds. Fastlock is called with a pointer to shared data. In the general case locks do not collide. So the cost of fastlock is the cost of a tset. In the case of collision, the high-order bit was set (tset(mem, 0x80000000) and the fastlock system call was called. The process waiting on the lock then slept. The owner of the lock can do one of two things when it frees the lock: 1) if no collide (mem&0x80000000 == 0), just clear the lock 2) otherwise, clear the lock and call a system call which wakes up the first sleeper on the lock. End result: very very fast locks, quite a bit faster than anything else. ron Ron Minnich |"Failure is not an option" -- Gene Kranz rminnich@sarnoff.com | -- except, of course, on Microsoft products (609)-734-3120 | ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html