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