Date: Mon, 30 Oct 2006 11:25:51 +0100 From: gnn@freebsd.org To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: libthr status Message-ID: <m2lkmyksls.wl%gnn@neville-neil.com> In-Reply-To: <200610301649.26429.davidxu@freebsd.org> References: <200610301649.26429.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Thanks, George
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m2lkmyksls.wl%gnn>