Re: Critical Sections for userland.

On Oct 4, 2007, at 10:43 AM, Daniel Eischen wrote:

> On Thu, 4 Oct 2007, Alfred Perlstein wrote:
>
>> * Daniel Eischen <[e-mail]> [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
[e-mail]


_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[e-mail]"