pthread_specific.c revision 1.5
1/*	$NetBSD: pthread_specific.c,v 1.5 2003/02/15 04:39:16 nathanw Exp $	*/
2
3/*-
4 * Copyright (c) 2001 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/* Functions and structures dealing with thread-specific data */
40#include <errno.h>
41#include <sys/cdefs.h>
42
43#include "pthread.h"
44#include "pthread_int.h"
45
46static pthread_mutex_t tsd_mutex = PTHREAD_MUTEX_INITIALIZER;
47static int nextkey;
48int pthread__tsd_alloc[PTHREAD_KEYS_MAX];
49void (*pthread__tsd_destructors[PTHREAD_KEYS_MAX])(void *);
50
51__strong_alias(__libc_thr_keycreate,pthread_key_create)
52__strong_alias(__libc_thr_setspecific,pthread_setspecific)
53__strong_alias(__libc_thr_getspecific,pthread_getspecific)
54__strong_alias(__libc_thr_keydelete,pthread_key_delete)
55
56int
57pthread_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 avaliable 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
97int
98pthread_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 this arguemnt 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
175int
176pthread_setspecific(pthread_key_t key, const void *value)
177{
178	pthread_t self;
179
180	if (pthread__tsd_alloc[key] == 0)
181		return EINVAL;
182
183	self = pthread__self();
184	/*
185	 * We can't win here on constness. Having been given a
186	 * "const void *", we can only assign it to other const void *,
187	 * and return it from functions that are const void *, without
188	 * generating a warning.
189	 */
190	/*LINTED const cast*/
191	self->pt_specific[key] = (void *) value;
192
193	return 0;
194}
195
196void*
197pthread_getspecific(pthread_key_t key)
198{
199	pthread_t self;
200
201	if (pthread__tsd_alloc[key] == 0)
202		return NULL;
203
204	self = pthread__self();
205	return (self->pt_specific[key]);
206}
207
208/* Perform thread-exit-time destruction of thread-specific data. */
209void
210pthread__destroy_tsd(pthread_t self)
211{
212	int i, done, iterations;
213	void *val;
214	void (*destructor)(void *);
215
216	/* Butenhof, section 5.4.2 (page 167):
217	 *
218	 * ``Also, Pthreads sets the thread-specific data value for a
219	 * key to NULL before calling that key's destructor (passing
220	 * the previous value of the key) when a thread terminates [*].
221	 * ...
222	 * [*] That is, unfortunately, not what the standard
223	 * says. This is one of the problems with formal standards -
224	 * they say what they say, not what they were intended to
225	 * say. Somehow, an error crept in, and the sentence
226	 * specifying that "the implementation clears the
227	 * thread-specific data value before calling the destructor"
228	 * was deleted. Nobody noticed, and the standard was approved
229	 * with the error. So the standard says (by omission) that if
230	 * you want to write a portable application using
231	 * thread-specific data, that will not hang on thread
232	 * termination, you must call pthread_setspecific within your
233	 * destructor function to change the value to NULL. This would
234	 * be silly, and any serious implementation of Pthreads will
235	 * violate the standard in this respect. Of course, the
236	 * standard will be fixed, probably by the 1003.1n amendment
237	 * (assorted corrections to 1003.1c-1995), but that will take
238	 * a while.''
239	 */
240
241	iterations = PTHREAD_DESTRUCTOR_ITERATIONS;
242	do {
243		done = 1;
244		for (i = 0; i < PTHREAD_KEYS_MAX; i++) {
245			if (self->pt_specific[i] != NULL) {
246				pthread_mutex_lock(&tsd_mutex);
247				destructor = pthread__tsd_destructors[i];
248				pthread_mutex_unlock(&tsd_mutex);
249			    if (destructor != NULL) {
250				    done = 0;
251				    val = self->pt_specific[i];
252				    self->pt_specific[i] = NULL; /* see above */
253				    (*destructor)(val);
254			    }
255			}
256		}
257	} while (!done && iterations--);
258}
259