From owner-cvs-all Wed Sep 30 19:36:22 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA23112 for cvs-all-outgoing; Wed, 30 Sep 1998 19:36:22 -0700 (PDT) (envelope-from owner-cvs-all) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA23054; Wed, 30 Sep 1998 19:36:07 -0700 (PDT) (envelope-from dillon@backplane.com) Received: (dillon@localhost) by apollo.backplane.com (8.9.1/8.6.5) id TAA01080; Wed, 30 Sep 1998 19:35:28 -0700 (PDT) Date: Wed, 30 Sep 1998 19:35:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199810010235.TAA01080@apollo.backplane.com> To: John Birrell Cc: nash@mcs.net (Alex Nash), jb@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_gc.c Makefile.inc uthread_init.c uthread_find_thread.c uthread_kern.c uthread_cre References: <199810010202.MAA07069@cimlogic.com.au> Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Although this isn't really related to the original thread, I would like to point out that there is a *third* choice, one that runs in between a spinlock and a mutex lock. That choice is to put a synchronous context switch in the middle of the spinlock (and variations thereof). I do this all the time for 'kernel' threads (non-FreeBSD OS) because the context switch winds up being a nop if no other task are ready to run on that cpu. If there is another task ready to run, it can be switched to with a simple register push/pop (just slightly slower then a subroutine call) and *without* having to do any complex dequeueing/queueing memory ops of the task node. It is especially useful for medium-sized bits of code and tends to result in more efficient use of the cpu (and an easily measureable counter to determine how much overhead the OS is imposing... the context switch counter). And, as well, extremely useful if you are doing asynchronous message passing between cpu's or if you are implementing an asynchronous device interface even for synchronous device calls where you think you will get a reply quickly if the other thread had a chance to run for a slot. -Matt :> might occur: : :It doesn't. A thread can't tell from the spinlock value if _it_ locked the :lock or another thread did. All that it knows is that the lock is locked. :The thread implementation has to remember what it has locked in order to :avoid deadlocks. This means that there is very little performance hit in :protecting code with spinlocks. The expectation is that the spinlock will :only be locked for a short time. Locks with longer duration require mutex :and condition variable pairs so that a blocked thread is put to sleep until :the mutex becomes available. : :-- :John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ :CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response)