pthread_tsd.c revision 1.7.8.2 1 1.7.8.2 martin /* $NetBSD: pthread_tsd.c,v 1.7.8.2 2008/04/28 20:23:02 martin Exp $ */
2 1.7.8.2 martin
3 1.7.8.2 martin /*-
4 1.7.8.2 martin * Copyright (c) 2001, 2007 The NetBSD Foundation, Inc.
5 1.7.8.2 martin * All rights reserved.
6 1.7.8.2 martin *
7 1.7.8.2 martin * This code is derived from software contributed to The NetBSD Foundation
8 1.7.8.2 martin * by Nathan J. Williams, and by Andrew Doran.
9 1.7.8.2 martin *
10 1.7.8.2 martin * Redistribution and use in source and binary forms, with or without
11 1.7.8.2 martin * modification, are permitted provided that the following conditions
12 1.7.8.2 martin * are met:
13 1.7.8.2 martin * 1. Redistributions of source code must retain the above copyright
14 1.7.8.2 martin * notice, this list of conditions and the following disclaimer.
15 1.7.8.2 martin * 2. Redistributions in binary form must reproduce the above copyright
16 1.7.8.2 martin * notice, this list of conditions and the following disclaimer in the
17 1.7.8.2 martin * documentation and/or other materials provided with the distribution.
18 1.7.8.2 martin *
19 1.7.8.2 martin * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
20 1.7.8.2 martin * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
21 1.7.8.2 martin * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
22 1.7.8.2 martin * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
23 1.7.8.2 martin * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
24 1.7.8.2 martin * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
25 1.7.8.2 martin * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
26 1.7.8.2 martin * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
27 1.7.8.2 martin * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
28 1.7.8.2 martin * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
29 1.7.8.2 martin * POSSIBILITY OF SUCH DAMAGE.
30 1.7.8.2 martin */
31 1.7.8.2 martin
32 1.7.8.2 martin #include <sys/cdefs.h>
33 1.7.8.2 martin __RCSID("$NetBSD: pthread_tsd.c,v 1.7.8.2 2008/04/28 20:23:02 martin Exp $");
34 1.7.8.2 martin
35 1.7.8.2 martin /* Functions and structures dealing with thread-specific data */
36 1.7.8.2 martin #include <errno.h>
37 1.7.8.2 martin
38 1.7.8.2 martin #include "pthread.h"
39 1.7.8.2 martin #include "pthread_int.h"
40 1.7.8.2 martin
41 1.7.8.2 martin static pthread_mutex_t tsd_mutex = PTHREAD_MUTEX_INITIALIZER;
42 1.7.8.2 martin static int nextkey;
43 1.7.8.2 martin void *pthread__tsd_alloc[PTHREAD_KEYS_MAX];
44 1.7.8.2 martin void (*pthread__tsd_destructors[PTHREAD_KEYS_MAX])(void *);
45 1.7.8.2 martin
46 1.7.8.2 martin __strong_alias(__libc_thr_keycreate,pthread_key_create)
47 1.7.8.2 martin __strong_alias(__libc_thr_keydelete,pthread_key_delete)
48 1.7.8.2 martin
49 1.7.8.2 martin int
50 1.7.8.2 martin pthread_key_create(pthread_key_t *key, void (*destructor)(void *))
51 1.7.8.2 martin {
52 1.7.8.2 martin int i;
53 1.7.8.2 martin
54 1.7.8.2 martin /* Get a lock on the allocation list */
55 1.7.8.2 martin pthread_mutex_lock(&tsd_mutex);
56 1.7.8.2 martin
57 1.7.8.2 martin /* Find an available slot */
58 1.7.8.2 martin /* 1. Search from "nextkey" to the end of the list. */
59 1.7.8.2 martin for (i = nextkey; i < PTHREAD_KEYS_MAX; i++)
60 1.7.8.2 martin if (pthread__tsd_alloc[i] == NULL)
61 1.7.8.2 martin break;
62 1.7.8.2 martin
63 1.7.8.2 martin if (i == PTHREAD_KEYS_MAX) {
64 1.7.8.2 martin /* 2. If that didn't work, search from the start
65 1.7.8.2 martin * of the list back to "nextkey".
66 1.7.8.2 martin */
67 1.7.8.2 martin for (i = 0; i < nextkey; i++)
68 1.7.8.2 martin if (pthread__tsd_alloc[i] == NULL)
69 1.7.8.2 martin break;
70 1.7.8.2 martin
71 1.7.8.2 martin if (i == nextkey) {
72 1.7.8.2 martin /* If we didn't find one here, there isn't one
73 1.7.8.2 martin * to be found.
74 1.7.8.2 martin */
75 1.7.8.2 martin pthread_mutex_unlock(&tsd_mutex);
76 1.7.8.2 martin return EAGAIN;
77 1.7.8.2 martin }
78 1.7.8.2 martin }
79 1.7.8.2 martin
80 1.7.8.2 martin /* Got one. */
81 1.7.8.2 martin pthread__tsd_alloc[i] = (void *)__builtin_return_address(0);
82 1.7.8.2 martin nextkey = (i + 1) % PTHREAD_KEYS_MAX;
83 1.7.8.2 martin pthread__tsd_destructors[i] = destructor;
84 1.7.8.2 martin pthread_mutex_unlock(&tsd_mutex);
85 1.7.8.2 martin *key = i;
86 1.7.8.2 martin
87 1.7.8.2 martin return 0;
88 1.7.8.2 martin }
89 1.7.8.2 martin
90 1.7.8.2 martin int
91 1.7.8.2 martin pthread_key_delete(pthread_key_t key)
92 1.7.8.2 martin {
93 1.7.8.2 martin
94 1.7.8.2 martin /*
95 1.7.8.2 martin * This is tricky. The standard says of pthread_key_create()
96 1.7.8.2 martin * that new keys have the value NULL associated with them in
97 1.7.8.2 martin * all threads. According to people who were present at the
98 1.7.8.2 martin * standardization meeting, that requirement was written
99 1.7.8.2 martin * before pthread_key_delete() was introduced, and not
100 1.7.8.2 martin * reconsidered when it was.
101 1.7.8.2 martin *
102 1.7.8.2 martin * See David Butenhof's article in comp.programming.threads:
103 1.7.8.2 martin * Subject: Re: TSD key reusing issue
104 1.7.8.2 martin * Message-ID: <u97d8.29$fL6.200 (at) news.cpqcorp.net>
105 1.7.8.2 martin * Date: Thu, 21 Feb 2002 09:06:17 -0500
106 1.7.8.2 martin * http://groups.google.com/groups?hl=en&selm=u97d8.29%24fL6.200%40news.cpqcorp.net
107 1.7.8.2 martin *
108 1.7.8.2 martin * Given:
109 1.7.8.2 martin *
110 1.7.8.2 martin * 1: Applications are not required to clear keys in all
111 1.7.8.2 martin * threads before calling pthread_key_delete().
112 1.7.8.2 martin * 2: Clearing pointers without running destructors is a
113 1.7.8.2 martin * memory leak.
114 1.7.8.2 martin * 3: The pthread_key_delete() function is expressly forbidden
115 1.7.8.2 martin * to run any destructors.
116 1.7.8.2 martin *
117 1.7.8.2 martin * Option 1: Make this function effectively a no-op and
118 1.7.8.2 martin * prohibit key reuse. This is a possible resource-exhaustion
119 1.7.8.2 martin * problem given that we have a static storage area for keys,
120 1.7.8.2 martin * but having a non-static storage area would make
121 1.7.8.2 martin * pthread_setspecific() expensive (might need to realloc the
122 1.7.8.2 martin * TSD array).
123 1.7.8.2 martin *
124 1.7.8.2 martin * Option 2: Ignore the specified behavior of
125 1.7.8.2 martin * pthread_key_create() and leave the old values. If an
126 1.7.8.2 martin * application deletes a key that still has non-NULL values in
127 1.7.8.2 martin * some threads... it's probably a memory leak and hence
128 1.7.8.2 martin * incorrect anyway, and we're within our rights to let the
129 1.7.8.2 martin * application lose. However, it's possible (if unlikely) that
130 1.7.8.2 martin * the application is storing pointers to non-heap data, or
131 1.7.8.2 martin * non-pointers that have been wedged into a void pointer, so
132 1.7.8.2 martin * we can't entirely write off such applications as incorrect.
133 1.7.8.2 martin * This could also lead to running (new) destructors on old
134 1.7.8.2 martin * data that was never supposed to be associated with that
135 1.7.8.2 martin * destructor.
136 1.7.8.2 martin *
137 1.7.8.2 martin * Option 3: Follow the specified behavior of
138 1.7.8.2 martin * pthread_key_create(). Either pthread_key_create() or
139 1.7.8.2 martin * pthread_key_delete() would then have to clear the values in
140 1.7.8.2 martin * every thread's slot for that key. In order to guarantee the
141 1.7.8.2 martin * visibility of the NULL value in other threads, there would
142 1.7.8.2 martin * have to be synchronization operations in both the clearer
143 1.7.8.2 martin * and pthread_getspecific(). Putting synchronization in
144 1.7.8.2 martin * pthread_getspecific() is a big performance lose. But in
145 1.7.8.2 martin * reality, only (buggy) reuse of an old key would require
146 1.7.8.2 martin * this synchronization; for a new key, there has to be a
147 1.7.8.2 martin * memory-visibility propagating event between the call to
148 1.7.8.2 martin * pthread_key_create() and pthread_getspecific() with that
149 1.7.8.2 martin * key, so setting the entries to NULL without synchronization
150 1.7.8.2 martin * will work, subject to problem (2) above. However, it's kind
151 1.7.8.2 martin * of slow.
152 1.7.8.2 martin *
153 1.7.8.2 martin * Note that the argument in option 3 only applies because we
154 1.7.8.2 martin * keep TSD in ordinary memory which follows the pthreads
155 1.7.8.2 martin * visibility rules. The visibility rules are not required by
156 1.7.8.2 martin * the standard to apply to TSD, so the argument doesn't
157 1.7.8.2 martin * apply in general, just to this implementation.
158 1.7.8.2 martin */
159 1.7.8.2 martin
160 1.7.8.2 martin /* For the momemt, we're going with option 1. */
161 1.7.8.2 martin pthread_mutex_lock(&tsd_mutex);
162 1.7.8.2 martin pthread__tsd_destructors[key] = NULL;
163 1.7.8.2 martin pthread_mutex_unlock(&tsd_mutex);
164 1.7.8.2 martin
165 1.7.8.2 martin return 0;
166 1.7.8.2 martin }
167 1.7.8.2 martin
168 1.7.8.2 martin /* Perform thread-exit-time destruction of thread-specific data. */
169 1.7.8.2 martin void
170 1.7.8.2 martin pthread__destroy_tsd(pthread_t self)
171 1.7.8.2 martin {
172 1.7.8.2 martin int i, done, iterations;
173 1.7.8.2 martin void *val;
174 1.7.8.2 martin void (*destructor)(void *);
175 1.7.8.2 martin
176 1.7.8.2 martin if (!self->pt_havespecific)
177 1.7.8.2 martin return;
178 1.7.8.2 martin pthread_mutex_unlock(&self->pt_lock);
179 1.7.8.2 martin
180 1.7.8.2 martin /* Butenhof, section 5.4.2 (page 167):
181 1.7.8.2 martin *
182 1.7.8.2 martin * ``Also, Pthreads sets the thread-specific data value for a
183 1.7.8.2 martin * key to NULL before calling that key's destructor (passing
184 1.7.8.2 martin * the previous value of the key) when a thread terminates [*].
185 1.7.8.2 martin * ...
186 1.7.8.2 martin * [*] That is, unfortunately, not what the standard
187 1.7.8.2 martin * says. This is one of the problems with formal standards -
188 1.7.8.2 martin * they say what they say, not what they were intended to
189 1.7.8.2 martin * say. Somehow, an error crept in, and the sentence
190 1.7.8.2 martin * specifying that "the implementation clears the
191 1.7.8.2 martin * thread-specific data value before calling the destructor"
192 1.7.8.2 martin * was deleted. Nobody noticed, and the standard was approved
193 1.7.8.2 martin * with the error. So the standard says (by omission) that if
194 1.7.8.2 martin * you want to write a portable application using
195 1.7.8.2 martin * thread-specific data, that will not hang on thread
196 1.7.8.2 martin * termination, you must call pthread_setspecific within your
197 1.7.8.2 martin * destructor function to change the value to NULL. This would
198 1.7.8.2 martin * be silly, and any serious implementation of Pthreads will
199 1.7.8.2 martin * violate the standard in this respect. Of course, the
200 1.7.8.2 martin * standard will be fixed, probably by the 1003.1n amendment
201 1.7.8.2 martin * (assorted corrections to 1003.1c-1995), but that will take
202 1.7.8.2 martin * a while.''
203 1.7.8.2 martin */
204 1.7.8.2 martin
205 1.7.8.2 martin iterations = 4; /* We're not required to try very hard */
206 1.7.8.2 martin do {
207 1.7.8.2 martin done = 1;
208 1.7.8.2 martin for (i = 0; i < PTHREAD_KEYS_MAX; i++) {
209 1.7.8.2 martin if (self->pt_specific[i] != NULL) {
210 1.7.8.2 martin pthread_mutex_lock(&tsd_mutex);
211 1.7.8.2 martin destructor = pthread__tsd_destructors[i];
212 1.7.8.2 martin pthread_mutex_unlock(&tsd_mutex);
213 1.7.8.2 martin if (destructor != NULL) {
214 1.7.8.2 martin done = 0;
215 1.7.8.2 martin val = self->pt_specific[i];
216 1.7.8.2 martin self->pt_specific[i] = NULL; /* see above */
217 1.7.8.2 martin (*destructor)(val);
218 1.7.8.2 martin }
219 1.7.8.2 martin }
220 1.7.8.2 martin }
221 1.7.8.2 martin } while (!done && iterations--);
222 1.7.8.2 martin
223 1.7.8.2 martin self->pt_havespecific = 0;
224 1.7.8.2 martin pthread_mutex_lock(&self->pt_lock);
225 1.7.8.2 martin }
226