From owner-freebsd-arch  Sat Jul  8 18:13:39 2000
Delivered-To: freebsd-arch@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 558)
	id 880E337BA97; Sat,  8 Jul 2000 18:13:38 -0700 (PDT)
To: jdp@FreeBSD.ORG
Subject: yield(2) (was Re: cvs commit: src/libexec/rtld-elf rtld.c rtld.h lockdflt.c)
Cc: freebsd-arch@FreeBSD.ORG
Message-Id: <20000709011338.880E337BA97@hub.freebsd.org>
Date: Sat,  8 Jul 2000 18:13:38 -0700 (PDT)
From: hsu@FreeBSD.ORG (Jeffrey Hsu)
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

  Spinlocks are the only kinds of locks that work with all thread
  packages.  But on uniprocessor systems they can be inefficient,
  because while a contender for the lock is spinning the holder of the
  lock cannot make any progress toward releasing it.  To alleviate
  this disadvantage I have borrowed a trick from Sleepycat's Berkeley
  DB implementation.  When spinning for a lock, the requester does a
  nanosleep() call for 1 usec. each time around the loop.  This will
  generally yield the CPU to other threads, allowing the lock holder
  to finish its business and release the lock.

What do you think of adding a real yield(2) system call?  I do the
nanosleep too in some locking code I use for a pre-forked server (like
Apache), but I am unhappy with that.  I chosed 100ms as the sleep time
because that's one scheduler quantum (or used to be).  It wasn't clear
to me that a nanosleep of anything less than a quantum would guarantee
a yield.

							Jeffrey


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message