higher speed mutexes

Petri Helenius pete at he.iki.fi
Sat Jan 8 10:24:43 PST 2005

David Xu wrote:

> Petri Helenius wrote:
>> David Xu wrote:
>>> I will have low overhead pthread library available soon, for
>>> simple mutex, it is only an atomic_cmpset_long() plus a function
>>> call (pthread_mutex_lock) overhead.
>> Sounds great. Will this change the performance of rwlocks or is 
>> simple mutex preferred for performance sensitive applications?
>> Is this something that I could drop on top of RELENG_5 or RELENG_5_3 
>> or is CURRENT required?
>> Do you have this in some public depository already?
> I have put it there:
> http://people.freebsd.org/~davidxu/libthread.tgz
> It can only run on newest -CURRENT kernel.

Is this something that is going to appear on 5.x eventually or only 6.0 ?

> It is a simplified version of libpthread plus some ideas from libthr.
> It is different with libpthread, it uses thr + umtx interfaces and does
> not have signal wrapper, it is in very simple shape.

Does this say that signal handling is broken/non-functional with this 
library or that it does not need it to work properly?

> I have rewritten simple mutex code to use umtx cmpset atomic instruction.
> Condition variable code is also rewritten, now simple mutex and condition
> variable both can be shared between processes once pthread.h is changed
> to define mutex and other synchronization objects in C structure style
> (current it was typedefed as a structure pointer, which prevents them 
> from
> being shared between processes via mmap() ), also I believe semaphore
> and rwlock can also be shared between processes  once pthread.h is 
> updated.

What happens if the process holding the lock dies?

> In detail, I don't use thr_suspend and thr_wakeup, I use more reliable 
> way:
> umtx_wait + umtx_wake, I have added them into kernel sometimes ago.
I was looking at the umtx routines and wondering if I could use them 
instead of pthread API.

> So I would like to see this library in tree, and let me start to work on
> process sharable synchronization objects in near future.

I assume the code using these libraries need also to be recompiled from 
5.3 ?


More information about the freebsd-threads mailing list