Date: Fri, 31 Jan 1997 09:43:51 -0500 (EST) From: "Ron G. Minnich" <rminnich@Sarnoff.COM> To: Andrew.Gordon@net-tel.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: Re(2): Using rfork() / threads Message-ID: <Pine.SUN.3.91.970131093856.16303C-100000@terra> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.970131093856.16303C-100000>