From owner-freebsd-threads@FreeBSD.ORG Sun Apr 27 21:58:20 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA0437B401 for ; Sun, 27 Apr 2003 21:58:20 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44FBD43FB1 for ; Sun, 27 Apr 2003 21:58:20 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3S4wJBg018152; Mon, 28 Apr 2003 00:58:19 -0400 (EDT) Received: from localhost (eischen@localhost)h3S4wHNi018148; Mon, 28 Apr 2003 00:58:19 -0400 (EDT) Date: Mon, 28 Apr 2003 00:58:17 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <007401c30d1a$da3d7f40$0701a8c0@tiger> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: pthread_join X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 04:58:21 -0000 On Mon, 28 Apr 2003, David Xu wrote: > In thr_cleanup(), joinee accesses joiner without holding joiner's sched lock, > it is possible when joinee accesses joiner, the joiner may disappear (canceled). > > if ((joiner->state == PS_JOIN) && > (joiner->join_status.thread == thread)) { > joiner->join_status.thread = NULL; Yes, when canceling we need to take the joinee's scheduling lock. I think we need to add a reference to the thread so it doesn't go away while we release the current lock and take the joiner's lock. I think processing the joiner can be done in pthread_exit() instead of thr_cleanup(). That's the way libc_r does it; I moved it into thr_kern in libpthread, but it doesn't need to be there. We could also have another lock just for joins. Or use each thread's lock. Each thread has a lock, similar to proc lock in the kernel, but they're not currently used for anything yet. I envisioned using the proc lock whenever we needed to modify something in the thread, but just used the scheduling locks because it was easier. I'm working on some signal fixes and some other fixes to hopefully fix your SMP problems. I want to try these fixes before making _thr_sched_switch() atomic (your SMP changes). -- Dan Eischen