From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 5 01:15:37 2007 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C77E16A420; Fri, 5 Oct 2007 01:15:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.79]) by mx1.freebsd.org (Postfix) with ESMTP id 6878C13C4AC; Fri, 5 Oct 2007 01:15:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpoutm.mac.com (Xserve/smtpout016/MantshX 4.0) with ESMTP id l950eORW024861; Thu, 4 Oct 2007 17:40:24 -0700 (PDT) Received: from [172.24.104.86] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin04/MantshX 4.0) with ESMTP id l950eMVG003106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Oct 2007 17:40:23 -0700 (PDT) In-Reply-To: References: <20071003015231.GJ31826@elvis.mu.org> <86zlyzqmgo.fsf@ds4.des.no> <20071004094821.GM31826@elvis.mu.org> <86ejgbqjvr.fsf@ds4.des.no> <20071004101902.GN31826@elvis.mu.org> <20071004170353.GR31826@elvis.mu.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 4 Oct 2007 17:40:07 -0700 To: Daniel Eischen X-Mailer: Apple Mail (2.752.3) Cc: hackers@freebsd.org, Dag-Erling Sm??rgrav , Alfred Perlstein Subject: Re: Critical Sections for userland. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2007 01:15:37 -0000 On Oct 4, 2007, at 10:43 AM, Daniel Eischen wrote: > On Thu, 4 Oct 2007, Alfred Perlstein wrote: > >> * Daniel Eischen [071004 06:05] wrote: >>> >>> His point about telling us what you're really doing, so we might >>> off other ways to do it is valid. >>> >>> We don't know why you are using homegrown user-level spinlocks >>> instead of pthread mutexes. Priority ceiling mutexes and running >>> in SCHED_RR or SCHED_FIFO is really what tries to address this >>> problem, at least from the vague desciption you give. If you >>> have tried this and they don't work correctly, then one solution >>> is to fix them ;-) >> >> First of all we're stuck on 6.x, how is threads on this platform? > > I don't _think_ there is anything prohibitive of MFC'ing > any libthr bug fixes into 6.x. I would have thought that > you would have tried libthr on 6.x and possibly offered up > "libthr performance sucks for me, and here's why" :-) Alfred: The Hurricane team uses 1x1 threading on PowerPC without problems. The patch below fixes a NULL pointer dereference in the POSIX priority cases: diff -up /b/marcelm/freebsd/6.x/src/lib/libthr/thread/thr_mutex.c ./ thr_mutex.c --- /b/marcelm/freebsd/6.x/src/lib/libthr/thread/thr_mutex.c Sun Jan 15 21:36:30 2006 +++ ./thr_mutex.c Sun Sep 9 20:58:20 2007 @@ -629,10 +629,14 @@ mutex_lock_common(struct pthread *curthr /* Unlock the mutex structure: */ THR_LOCK_RELEASE(curthread, &(*m)- >m_lock); - clock_gettime(CLOCK_REALTIME, &ts); - TIMESPEC_SUB(&ts2, abstime, &ts); - ret = _thr_umtx_wait(&curthread- >cycle, cycle, - &ts2); + if (abstime != NULL) { + clock_gettime(CLOCK_REALTIME, &ts); + TIMESPEC_SUB(&ts2, abstime, &ts); + ret = _thr_umtx_wait (&curthread->cycle, + cycle, &ts2); + } else + ret = _thr_umtx_wait (&curthread->cycle, + cycle, NULL); if (ret == EINTR) ret = 0; @@ -712,10 +716,14 @@ mutex_lock_common(struct pthread *curthr /* Unlock the mutex structure: */ THR_LOCK_RELEASE(curthread, &(*m)- >m_lock); - clock_gettime(CLOCK_REALTIME, &ts); - TIMESPEC_SUB(&ts2, abstime, &ts); - ret = _thr_umtx_wait(&curthread- >cycle, cycle, - &ts2); + if (abstime != NULL) { + clock_gettime(CLOCK_REALTIME, &ts); + TIMESPEC_SUB(&ts2, abstime, &ts); + ret = _thr_umtx_wait (&curthread->cycle, + cycle, &ts2); + } else + ret = _thr_umtx_wait (&curthread->cycle, + cycle, NULL); if (ret == EINTR) ret = 0; > I don't know if anyone other than possibly David Xu have > tested SCHED_RR or SCHED_FIFO and priority ceiling mutexes, > so they may not work as they're suppose to. We use it successfully with the above patch. FYI, -- Marcel Moolenaar xcllnt@mac.com