From owner-freebsd-current Fri Mar 10 13:57:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 9FC6337B82C for ; Fri, 10 Mar 2000 13:57:24 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id NAA24366; Fri, 10 Mar 2000 13:57:21 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id NAA43351; Fri, 10 Mar 2000 13:57:20 -0800 (PST) (envelope-from jdp@polstra.com) Date: Fri, 10 Mar 2000 13:57:20 -0800 (PST) Message-Id: <200003102157.NAA43351@vashon.polstra.com> To: bloom@acm.org Subject: Re: More "ld-elf.so.1: assert failed" messages In-Reply-To: <38C8610C.E17A41EF@acm.org> References: <13611.952595759@zippy.cdrom.com> <200003100054.BAA64158@saturn.kn-bremen.de> <38C8610C.E17A41EF@acm.org> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <38C8610C.E17A41EF@acm.org>, Jim Bloom wrote: [when dllockinit() should be called] > It should be called somewhere between the starting of the process > and the creation of the second thread. There is no problem if there > is only one thread. > > THREAD Create would be fine as long as it sets a variable accessible > to all threads indicating dllockinit has been called. > > Another possible location would be a routine that initialize the > multithreading for the process. This routine may not exist in all > thread packages though. That is all correct. Dllockinit has to be called once only, before any threads have been forked but late enough so that it's safe to call the thread sychronization primitives. Ideally, a reader/writer lock should be used. But it will also work to use a simple mutex. In that case, rlock_acquire and wlock_aquire will be the same (lock the mutex). I'd recommend using a simple mutex unless the threads package already implements reader/writer locks. I really hope I can render all this nonsense unnecessary after the code freeze ends. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message