Date: Wed, 2 Jan 2002 16:24:44 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Peter Jeremy <peter.jeremy@alcatel.com.au>, Michal Mertl <mime@traveller.cz>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <200201030024.g030Oip60860@apollo.backplane.com> References: <XFMail.020102161300.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:Note that critical sections don't impose locking, right now they just disable
:interrupts on the local CPU. Eventually they will also prevent preemptions for
:any setrunqueue's done inside a critical section and defer the switches until
:the critical section is exited. If you pin processes/threads to CPU's when
:they get interrupted so they resume on the same CPU and only migrate at
:setrunqueue(), then you still might need to disable interrupts if your update
:of a per-CPU variable isn't atomic since when you return to the thread, it
:might do a modify-write of a stale variable. Think of an interrupt handler
:being interrupted by another interrupt. Thus, I think it would still be wise
:to disable interrupts for per-CPU stuff. At least, for ones that can be
:modified by interrupt handlers. Also, per-thread counters don't need locking.
But if it is protected by a mutex, and an interrupt occurs while you
hold the mutex, the interrupt thread will not be able to run (or
at least will wind up blocking while getting the mutex) until you release
your mutex, at which point your modifications have been synchronized out
(releasing the mutex ensures this).
The critical section stuff would be more palettable if it weren't so
expensive. Couldn't we just have a per-cpu critical section count
and defer the interrupt? (e.g. like the deferred mechanism we used for
spl()s). Then we would have an incredibly cheap mechanism for accessing
per-cpu caches (like per-cpu mbuf freelists, for example) which could
further be adapted for use by zalloc[i]() and malloc().
I am really beginning to hate not being able to depend on anything
without having to make expensive calls first. sti and cli are very
expensive instructions.
(We are really talking about two different ways to increment a counter
here... one way using a mutex for protection, the other way using a
critical section and per-cpu space).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201030024.g030Oip60860>