Date: Wed, 03 Apr 2002 13:11:21 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Jake Burkholder <jake@locore.ca>, smp@FreeBSD.ORG, "Andrew R. Reiter" <arr@FreeBSD.ORG> Subject: Re: Where to initialize certain locks... Message-ID: <3CAB6FF9.27C6288C@mindspring.com> References: <XFMail.20020403152904.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On 03-Apr-2002 Terry Lambert wrote: > > John Baldwin wrote: > >> We need mutexes prior to mi_startup(). > > > > There are really two problems with this theory: > > > > 1) You can't use them before the mutex system is initialized, > > which happens from mi_startup. > > Incorrect. It happens prior to mi_startup(). You missed my followup to myself, where I pointed out that the initi routine could be called anytime, and wasn't married to mi_startup. 8-). > > 2) There are no contended resources until after mi_startup > > starts the other CPU(s). > > But there is lots of code that we don't want to have to do stuff like: > > if (!cold) > mtx_lock(&foo_mtx); > else > /* just wing it */ > > Easier to just always acquire the locks and init them early enough. I understood that at the time I made the posting; I was (figuratively) sticking my tongue out at locking data vs. critical sectioning. 8^p In any case, the foo_init() could be called as early as you wanted; all it does is manipulate data in statically initialized data structures to create the initial linked list that can be extended at runtime, to solve the problem that started this thread. The only limit on it is that you can't call it before the subsystems on which it relies; so if initializing a mutex allocates memory or pages or does other evil, then you have to wait until that code is up (which is true, with or without my proposal). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CAB6FF9.27C6288C>