Date: Tue, 25 Mar 2003 21:59:40 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: arch@freebsd.org Subject: 1:1 Threading implementation. Message-ID: <20030325214028.K64602-100000@mail.chesapeake.net>
next in thread | raw e-mail | index | archive | help
I realize that many people have strong feelings on this topic. I'm asking everyone up front to try not to devolve this thread into a bikeshed. Thanks to the foundation provided by Julian, David Xu, Mini, Dan Eischen, and everyone else who has participated with KSE and libpthread development Mini and I have developed a 1:1 threading implementation. This code works in parallel with KSE and does not break it in any way. It actually helps bring M:N threading closer by testing out shared bits. I have successfully run mozilla 1.2.1 using this threading package. It still has some bugs and some incomplete corners but we're very close to being able to commit this. I'm going to post a link to the kernel portion of this code at the end of this mail. The library will come later. What this means is that for every pthread in an application there is one KSE and thread. There is also only one ksegroup per proc in this model. Since the kernel knows about all threads it handles all scheduling decisions and all signal delivery. I have followed the POSIX spec while implementing the signal code. I would really appreciate review from anyone who is intimately familiar with signals and threads. Included in this is an implementation of sigwait(), sigtimedwait(), and sigwaitinfo(). The user land mutexes are supported by kernel code. Uncontested acquires and releases are done entirely in application space using atomic instructions. Once there is contention the library falls back to system calls to handle the locks. There are no per lock kernel resources allocated. There is a user space safe atomic cmpset function that has been defined for x86 only at the moment. New architectures require only this function and the *context apis to run this threading package. There is no arch specific code in user space. The condition variables and other blocking situations are handled with sig*wait*() and a new signal, SIGTHR. There are many reasons that we went with a signal here. If anyone cares to know them, you may ask. There are only 4 system calls for threading. thr_create, thr_self, thr_exit, and thr_kill. The rest of the functionality is implemented in a library that has been heavily hacked up from the original libc_r. The reason we're doing this in parallel with the M:N effort is so that we can have reasonable threading sooner. As I stated before, this project is complimentary to KSE and does not prohibit it from working. I also think that the performance will be better or comparable in the majority of real applications. The kernel bits are available at http://www.chesapeake.net/~jroberson/thr.diff I'd like to get the signal code commited asap. It's the majority of the patch and I often have to resolve conflicts. There have been no regressions in KSE or non threaded applications with this signal code. Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030325214028.K64602-100000>