Date: Wed, 23 May 2001 13:11:45 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Brian Somers <brian@Awfulhak.org> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: RFC: unit_list routines Message-ID: <200105231711.NAA30721@khavrinen.lcs.mit.edu> In-Reply-To: <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org> References: <wollman@khavrinen.lcs.mit.edu> <200105231523.LAA29635@khavrinen.lcs.mit.edu> <200105231552.f4NFqwF05688@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 23 May 2001 16:52:58 +0100, Brian Somers <brian@Awfulhak.org> said: > The way I see it, holding and releasing mutexes will introduce > contention between consumers that only want to maintain a [completely > private] sparce array. I think the usual watchword is ``Don't optimize initialization.'' > Allocating a ``struct resource'' munges a completely separate > resource (allocated units) in with all of the existing resources I'm having a bit of difficulty understanding the point you're trying to make here. It's a general interface; you need a subset of that functionality. Your resource is not ``munged [...] in with all of the existing resources'' -- each resource is managed separately, through its rman structure. > of lists and backwards pointers to achieve something that means > nothing in the context of these allocated units. Those lists and backwards pointers are not there for the benefit of clients, and should be treated as opaque. Actually, the whole `struct resource' should be treated as opaque, although because accessors are provided as macros rather than functions it can't be made literally so. > Using bits when there are large numbers of units gets awkward. Just wrap it in macros. I almost posted an implementation with my last message, but decided that since it was so trivial it would be almost insulting for me to do so. -GAWollman 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?200105231711.NAA30721>