John Baldwin wrote:
> On 18-May-2002 Terry Lambert wrote:
> > John Baldwin wrote:
> >> > God, it's annoying that a statically declared mutex is not
> >> > defacto initialized.
> >> Is it in solaris?
> > It isn't in FreeBSD because of the need to link mutex'es into
> > the "witness protection program". 8-).
> Actually, there is more to it than that. Or at least, there will be
> when turnstiles are added (turnstiles require some function callouts
> to work properly).
It's the function callouts that are the problem. 8-(.
> > MUTEX_DECLARE(mutex_name).
> Umm, yes, like MTX_SYSINIT(). :)
No. An MTX_SYSINIT() that wrapped a declaration and a SYSINIT()
would als imply the definition of an static function to do the
initialization, that then got called by the SYSINIT() itself.
This is actually what I was saying was bad: a static function
per mutex declaration.
You really want to avoid the pthreads "mutex initializer" thing;
the compiler doesn't have code that can attach to data declarations
to fix the problem.
So, among other things, you want to use the same initializer function
instance for all statically declared mutexes.
So you have to use something other than a SYSINIT() for the declarations,
but you could use *one SYSINIT()* to do the pre-use initialization of
> > You could do this with a SYSINIT(), as has been suggested, but
> > that would add a relatively large per mutex overhead for each
> > one you want to declare, since you'd basically be repeating the
> > common components for doing the job for each and every mutex,
> > instead of sharing them.
> Umm, this is a boot-up thing so it's not that big of a deal, plus
> the actual code isn't duplicated, we call a common function for
> the actual mutex initialization.
Maybe. I don't think a large sysinit structure is as useful as an
array of addresses of mutexes needing initialization. There would
be a serious tempation in the former case to provide for some type
of non-uniform initialization of statically declared sysinit objects.
It would be nice if the non-uniformity could be limited to the fact
that if the WITNESS code was there, it needed to be linked onto the
With the WITNESS code not compiled into the kernel, I'd prefer not
to include the initialization code at all. It would encorage bad
practice, if it weren't conditional on WITNESS.
> > Technically, some later programmer could come along and recover
> > the linker set memory, actually, since it's only used once, for
> > the traversal, at kernel startup.
> Erm, they could do the same with the little mtx_args structs if
> they want to as well, but I think it's more effor than its worth.
Actually, I don't think they could.
The intermediate stage for that would really suck. The only way
to handle it is to use different ELF sections for that datam so
that you could discard the section later.
This is worthwhile for device probe code, maybe attach code, any
linker set contents, but not really for individial small structures
each getting jammed into their own page size object. 8-). You'd
need to do a lot more work, including KVA defragmentation by being
able to sectionally attribute anything in the paging path, to keep
it from being moved around, or the move-it-around code itself.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message