Date: Thu, 4 Oct 2007 17:40:07 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Daniel Eischen <deischen@freebsd.org> Cc: hackers@freebsd.org, Dag-Erling Sm??rgrav <des@des.no>, Alfred Perlstein <alfred@freebsd.org> Subject: Re: Critical Sections for userland. Message-ID: <ED70F979-5E0D-41A8-BCFD-032C4DFD97A7@mac.com> In-Reply-To: <Pine.GSO.4.64.0710041328001.10307@sea.ntplx.net> 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> <Pine.GSO.4.64.0710040900560.9250@sea.ntplx.net> <20071004170353.GR31826@elvis.mu.org> <Pine.GSO.4.64.0710041328001.10307@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 4, 2007, at 10:43 AM, Daniel Eischen wrote:
> On Thu, 4 Oct 2007, Alfred Perlstein wrote:
>
>> * Daniel Eischen <deischen@freebsd.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ED70F979-5E0D-41A8-BCFD-032C4DFD97A7>