1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
Some brief notes:
1) This package is intended to run on FreeBSD 4.0-current or
FreeBSD 3.X, with sources more recent than May 1, 1999, i386
processors only. If you are running an SMP kernel, you should
be using FreeBSD 4.0-current only.
Compile your applications that use Linux Threads with the following
command line options:
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -llthread -llgcc_r
Note that the include (-I..) directive shown here should appear before any other include
directive that would cause the compiler to find the FreeBSD file /usr/include/pthread.h.
Using the FreeBSD pthread.h instead of the linuxthreads pthread.h will result in an app
fails fails in many odd and maybe spectacular ways.
In order to facilitate porting applications which expect a libpthread, you can create
the following symlinks if you want:
ln -s /usr/local/lib/liblthread.a /usr/lib/libpthread.a
ln -s /usr/local/lib/liblthread_p.a /usr/lib/libpthread_p.a
ln -s /usr/local/lib/liblthread.so.0 /usr/lib/libpthread.so.0
ln -s /usr/local/lib/liblthread.so.0 /usr/lib/libpthread.so
/sbin/ldconfig -m /usr/lib
If you do this, you can instead use:
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -lpthread -llgcc_r
or
-D_THREAD_SAFE -I/usr/local/include/pthread/linuxthreads -kthread -llgcc_r
DO NOT use libc_r with Linux Threads, and do not compile/link with
the -pthread option (which pulls in libc_r). DO link with libc
(which you will get by default).
2) You should consider enabling the posix priority extensions
in your kernel. Adding the following to your kernel config
file before you execute config and before you remake the kernel
should suffice.
options "P1003_1B"
options "_KPOSIX_PRIORITY_SCHEDULING"
options "_KPOSIX_VERSION=199309L"
These options are not manditory.
3) If you plan on having lots of threads, check the sysctl value
of kern.maxproc. Each kernel thread counts against maxproc. You
can increase maxproc by changing the MAXUSERS value in your kernel
config file. maxproc is set at 20 + 16 * MAXUSERS.
4) Be aware of the following libc issues:
a) Not all libc calls are thread safe. Many are.
In particular gmtime, localtime, etc are not thread
safe. In general, where the pthreads spec calls for "_r"
functions, these are either not provided, or if provided
are not thread safe (in most cases) and the related
libc calls are not thread safe. This differs somewhat
from the FreeBSD libc_r library, where some, but not
all, of these functions are both thread safe and have
"_r" versions.
b) None of the libc calls that are supposed to be
cancellation points are implemented as such. There
is a lot of work that needs to be done on libc before
cancellation points will work correctly. Therefore,
while linux threads has the cancel functions implemented,
deferred cancellation will not really do anything, since
the co-operation needed from libc is not there.
5) There is a call implemented for FreeBSD (see stack.c):
int _pthread_setstackspacing(size_t spacing, size_t guardsize)
By default, Linux Threads spaces thread stacks 2MB apart, and
makes each thread stack an "autogrow" stack. If you know that
your maximum stack for any thread can be less than that, you
can decrease the spacing by calling this function. It must
be called before any other pthreads function calls, and it
will only succeed the first time its called. Note that the
pthread TLS and the guardsize will be included in the spacing.
ie. maximum stack size = spacing - TLSpagesize - guardsize.
The spacing must be a power of 2 times the pagesize (and if its
not, it will be rounded up to the next highest value that is).
6) Note that this is an older version of linuxthreads. More current
versions are at http://www.kernel.org/pub/linux/libs/glibc.
7) Known problems and issues:
a) It is possible that the instructions given above for including
liblgcc_r are not sufficent. liblgcc_r is a version of libgcc_r
linked against this linuxthreads package. It is intended that
applications link against this, rather than libgcc_r (which is
linked against libc_r) or libgcc (which is not thread safe).
The normal gcc link options cause libgcc to be included twice
in the link line (and libgcc_r twice when linking with the
-pthread option). It is therefore possible that a custom link
line needs to be generated that specifically excludes the
default libgcc and which includes liblgcc_r twice. There are
no known problems resulting from the link procedure suggested
above. However, compiling/linking with the "-v" option will
illustrate the issue, where lihgcc is included twice in
addition to liblgcc_r.
b) Since some point around Auguest 30 or later, dynamically linked
SMP applications have experienced problems with the dynamic linker.
Statically linked applications appear fine.
Specifically, some applications are not able to resolve dynamic
links as in this sample output:
root@chiricahua:/usr/ports/devel/linuxthreads/work/linuxthreads-0.71/Examples [119] ./ex4
Thread 400: allocated key 0
Thread 400: allocating buffer at 0x804b400
/usr/libexec/ld-elf.so.1: /usr/local/lib/liblthread.so.0: Undefined symbol "sigfillset"
The problem does not occur on every run, but rather intermittently,
and the undefined symbol is not always "sigfillset", thought
this is common.
It is possible that ld-elf.so needs to be made thread safe, and that
the problem is not unique to SMP but only exposed by the higher
concurrency of SMP threads. However, the problem has not been
fully diagnosed.
c) Since August 30 or maybe later, neither this version of FreeBSD
linuxthreads nor FreeBSD user threads (libc_r) have been able to
pass the ACE Reactor_Exception_Test using FreeBSD-current. See
http://www.pinyon.org/ace for information about ACE and compiling
it under FreeBSD. It is possible that PR/15228 is another illustration
of the same problem. In both cases the app aborts at line 3314 in
libgcc2.c in the __sjthrow function, because there is no exception
handler registered at that point.
Earlier, before August 30, both this version of linuxthreads as well]
as libc_r passed all the ACE thread tests. The cutoff date for the
onset of the problem could be later than August 30.
There has not been time to fully diagnose this problem. It occurs
on both SMP and UP systems.
|
