Date: Wed, 02 Jan 2002 19:50:18 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, 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: <3C33D4FA.3F7B09CD@mindspring.com> References: <XFMail.020102161300.jhb@FreeBSD.org> <200201030024.g030Oip60860@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > 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). It's a freaking statistic. Just keep "private" and "published" versions, increment the private version if you can't get the mutex, and increment the public and add any private to the public when you can. If you want to be even more clueful, then always inclrement the priuvate, and add the private to the public only if you can get the mutex when reading the statistics. This will make the code at interrupt run in deterministic time, which is a useful property. > 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(). It's a statistic: defer the statistic update, not the interrupt. -- Terry 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?3C33D4FA.3F7B09CD>