Skip site navigation (1)Skip section navigation (2)
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>