Both Coda and Arla make use of an LWP implementation originating at CMU.
I believe that the implementation can make use of timers to add
preemption, but know that in Coda preemption is not supported: LWPs are
used to represent in-process (potentially blocking) RPCs on both the
client and server, and are quite light weight, meaning low context-switch
overhead with minimal kernel involvement. As a result, AFS and Coda
servers tend to run with hundreds, if not thousands of threads: a feat not
possible in many 1:1 userland thread/kernel mappings (Linux kernel
threads, for example), and often not all that scalable in m:n models.
However, as with other library-based thread mechanisms, you have to be
careful to direct potentially blocking calls through the thread-aware
versions of the calls so as not to block all other threads. As the LWP
code used in AFS/Coda/Arla uses select() for blocking/timeout management,
there are some scalability issues with lots of blocked threads--these
might be improved through use of poll() or kqueue().
For reference, my recollection is that peemption-aware userland thread
libraries tend to make alot of timer syscalls, losing some of the
advantage of being a userland thread library (low context switch cost, few
transistions between user/kerneland). The AFS LWP code included a
fasttime() mechanism that took advantage of the ability to mmap kernel
memory under SunOS, allowing direct access to the timer variable in
kernel, without a context switch. I do not believe that native ports to
Linux/FreeBSD/et al have retained this capability, especially given its
requirements for privilege. However, it would be easy to imagine a kernel
module exporting a /dev/time, which had the singular ability of allowing
the mmaping of a page containing only the kernel's timer variables,
permitting syscall-free precise time access from userland using atomic
memory access calls.
Robert N M Watson
[EMAIL PROTECTED] http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
