From owner-freebsd-hackers Fri Jan 31 17:38:24 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA27443 for hackers-outgoing; Fri, 31 Jan 1997 17:38:24 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA27438 for ; Fri, 31 Jan 1997 17:38:20 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id BAA12981; Sat, 1 Feb 1997 01:38:03 GMT Date: Sat, 1 Feb 1997 10:38:03 +0900 (JST) From: Michael Hancock To: "Ron G. Minnich" cc: Andrew.Gordon@net-tel.co.uk, freebsd-hackers@FreeBSD.ORG Subject: Re: Re(2): Using rfork() / threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The Vahalia book mentions shared memory locks for 4.4BSD that worked essentially the same way. They were named mset, mwait, or something like that. Fastlock sounds cool, but shared memory locks are supposed to be fast. Instead of naming things like FastLock or TurboLock we should name them according to their function. i.e. synchronization primitives to use in shared memory. I prefer the mxxx conventions to categorize it with the mmap calls. On the otherhand, since rlock came from Plan 9 maybe we should look at Plan 9 synchronization. Regards, Mike Hancock On Fri, 31 Jan 1997, Ron G. Minnich wrote: > 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 > > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766