Date: Wed, 21 Jun 2006 10:09:16 +0200 From: Divacky Roman <xdivac02@stud.fit.vutbr.cz> To: David Xu <davidxu@freebsd.org> Cc: threads@freebsd.org, hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: TLS - implementing linux one in fbsd Message-ID: <20060621080916.GA81422@stud.fit.vutbr.cz> In-Reply-To: <200606210658.24741.davidxu@freebsd.org> References: <20060620120948.GA8288@stud.fit.vutbr.cz> <200606210658.24741.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Linux uses strict 1:1 threading so every thread is in fact process, so > > thread creation is done using plain clone()/fork(). FreeBSD uses M:N > > (including 1:1) threading. Threads are created via pthread_create() call to > > threading library. In kernel there's thr_new() syscall or thread_create() > > syscall. I didnt find the connection between threading library and kernel > > but I assume its using one of the syscalls > > > The M:N and 1:1 threading in FreeBSD use different mechanisms to > implement TLS, M:N implements it in userland, while 1:1 implements it in > kernel. the thr_new or thr_create are used for 1:1 threading, right > now libthr uses thr_new to atomically setup a thread, this includes, > storing TID, setting TLS, and maybe signal mask( not implemented ) , > cpu affinity mask etcs(not implemented), scheduling scope, in one word, > it is intended to map most part of pthread_attr into kernel world. but on the kernel level the implementation must be the same.. I mean the mangling of %gs. right? > > For setting up the GDT for the thread Linux uses syscall set_thread_area() > > (TODO - how exactly? its unclear what it does). I dont know how FreeBSD > > does it but I think it might be done via params to the syscalls (TODO - how > > is it done?) > > > If you use thr_new, it is not necessary to use set_thread_area, I am not sure > you need to change TLS pointer again after the thread is created, I think > only main thread may need this feature, in FreeBSD, setting thread's TLS > pointer is via libc function: _set_tp(void *tp). well.. in linux the thread creation and setting up the tls is done using separate syscalls. I plan to extend clone() syscall to use thr_create() or thr_new() (if the flags tell me its thread) but I am afraid I'l have to modify those syscalls to not to setup TLS (some flag) because linux wants to set it separately. > > set/get tid - does it relate to TLS at all? I dont think so but you never > > know. The tid thing is unclear to me. The clone() syscall is passed > > CLONE_CHILD_SETTID & CLONE_CHILD_CLEARTID which should be mutually > > exclusive. I dont believe much its a mistake.. but the code is clear: > > p->set_child_tid = (clone_flags & CLONE_CHILD_SETTID) ? child_tidptr : > > NULL; p->clear_child_tid = (clone_flags & CLONE_CHILD_CLEARTID) ? > > child_tidptr: NULL; > > > > kostik belousov pointed out that this is used for futexes, so not > > interesting for this > > > > > I think it is used for futex, and the childtid is use to implement > pthread_join and garbage collection in thread library, the parent tid > pointer (if I recall correctly) is used by parent thread to retrieve > child tid. this is the next step... I think all the magic is done in their libc (or somewhere) and I basically just need to malloc some space for this info and clear/set it on proces creation/exit > > Possible mapping from Linux to FreeBSD: > > > > To me it seems that the the set_thread_area() syscall is used in the > > process of thread creation to set where the tls is stored. In FreeBSD we > > use cpu_set_user_tls() for this. So it might be enough to just wrap call to > > cpu_set_user_tls() into the syscall. > cpu_set_user_tls is used by thr_new syscall internally to setup TLS pointer > before executing user code, the thr_new syscall's only user is libthr. the cpu_set_user_tls() is then what I need I think... maybe some modifications needed but it shuold be basiscally the thing. the linux syscall set_thread_area() just loads GDT with that info.. thats the same like ours cpu_set_use_tls(), right? thnx for your information! roman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060621080916.GA81422>