Date: Wed, 30 Sep 1998 19:35:28 -0700 (PDT) From: Matthew Dillon <dillon@backplane.com> To: John Birrell <jb@cimlogic.com.au> 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 Message-ID: <199810010235.TAA01080@apollo.backplane.com> References: <199810010202.MAA07069@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
<dillon@backplane.com> (Please include original email in any response)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810010235.TAA01080>