libthr status

gnn at gnn at
Mon Oct 30 10:26:28 UTC 2006

At Mon, 30 Oct 2006 16:49:26 +0800,
David Xu wrote:
> As some of you may know that I have been working on 1:1 threading
> for years on FreeBSD. In the past years, I have polished it again and
> again.

Thanks for posting this.

> 1) The current status of libthr is that all features listed in
> /usr/include/pthread.h and /usr/include/pthread_np.h are supported
> by libthr except followings:
> 1.1) libthr does not support PROCESS scope, a threads created in
> libthr is SYSTEM scope threads, a kernel thread within system
> contention scope. The PROCESS scope is supported by libpthread using
> userland scheduler.
> 1.2) libthr does not support PROCESS SHARED mutex and other pthread
> synchronous objects. Study pthread_mutexattr_setpshared if you are
> interested.  libpthread does not support the feature too. But libthr
> has better potential than libpthread to support it, since our kernel
> umtx code support shared memory map, study kern_umtx.c if you are
> interested.
> 1.3) libthr does not support some level of robust mutex which is
> found in recent Linux kernel and glibc and Solaris, this is only
> required if PROCESS SHARED mutex is supported. libpthread does not
> support the feature too.  This is not required by POSIX, but in some
> commercial implementations.
> 1.4) pthread_getconcurrency and pthread_setconcurrency in libthr are
> no-op, because it is 1:1 and does not have PROCESS scope thread.  it
> is supported by libpthread to tune number of UPCALL structures.
> 1.5) pthread_switch_add_np and pthread_switch_delete_np are no-op in
> libthr, they are remanet of libc_r.
> 1.6) setrlimit for number of kenrel threads, it is not done, one-day work.

Cool that it's only a day.  Is this something you're hacking on now?

> 1.7 CPU binding API, not done in libthr, found in other OSes.  libpthread
> does not support it either.
> 1.8 C++ object unwinding when pthread_exit is called(), I found it
> is support by debian Linux and Solaris, I have sample implementation
> for libthr.

Cool as well, though not as big a deal as setrlimit.

> 1.9) I forgot something.
> 2) Things can only be used by root:
> 2.1) the real-time scheduling options can only be used by root, e.g,
> if you call pthread_attr_setschedpolicy() with parameter SCHED_FIFO
> or SCHED_RR, the thread can only be created by root, normal user
> will get EPERM errno. you can use it in libpthread, but it is not
> real-time, it is a static priority scheduling in userland scheduler,
> if you want to preemptable other threads or processes in the system
> when playing real-time multimedia or military program, no way!
> 2.2) the real-time scheduling is not safe, it can deadlock itself and
> the whole system if program behavors incorrectly, it should only be
> used by trusted programs.

Are these (can these be) documented in the man pages?


More information about the freebsd-threads mailing list