1.0.23.59: bug 3b has been fixed a while now
[sbcl/tcr.git] / doc / internals / threads.texinfo
blob8fe35830185b18dc9e541b3ed4e7d981b8b579d1
1 @node Threads
2 @comment  node-name,  next,  previous,  up
3 @chapter Threads
5 @menu
6 * Implementation (Linux x86)::  
7 @end menu
9 @node Implementation (Linux x86)
10 @section Implementation (Linux x86/x86-64)
12 Threading is implemented using pthreads and some Linux specific bits
13 like futexes.
15 On x86 the per-thread local bindings for special variables is achieved
16 using the %fs segment register to point to a per-thread storage area.
17 This may cause interesting results if you link to foreign code that
18 expects threading or creates new threads, and the thread library in
19 question uses %fs in an incompatible way. On x86-64 the r12 register
20 has a similar role.
22 Queues require the @code{sys_futex} system call to be available: this
23 is the reason for the NPTL requirement.  We test at runtime that this
24 system call exists.
26 Garbage collection is done with the existing Conservative Generational
27 GC.  Allocation is done in small (typically 8k) regions: each thread
28 has its own region so this involves no stopping. However, when a
29 region fills, a lock must be obtained while another is allocated, and
30 when a collection is required, all processes are stopped.  This is
31 achieved by sending them signals, which may make for interesting
32 behaviour if they are interrupted in system calls.  The streams
33 interface is believed to handle the required system call restarting
34 correctly, but this may be a consideration when making other blocking
35 calls e.g. from foreign library code.
37 Large amounts of the SBCL library have not been inspected for
38 thread-safety.  Some of the obviously unsafe areas have large locks
39 around them, so compilation and fasl loading, for example, cannot be
40 parallelized.  Work is ongoing in this area.