From mboxrd@z Thu Jan  1 00:00:00 1970
From: mrs@wrs.com (Mike Stump)
To: hjl@lucon.org, libc-hacker@cygnus.com
Subject: Re: A patch for linuxthreads
Date: Wed, 17 Mar 1999 13:44:00 -0000
Message-id: <199903172144.NAA17458@kankakee.wrs.com>
X-SW-Source: 1999-03/msg00025.html

> From: hjl@lucon.org (H.J. Lu)
> To: libc-hacker@cygnus.com (GNU C Library)
> Date: Tue, 16 Mar 1999 20:28:23 -0800 (PST)

> The problem is we should not access those key data stuctures after
> a thread is terminared since they have been freed.

> The patch for Versions fixes another bug. 

> Index: specific.c
> ===================================================================
> RCS file: /work/cvs/gnu/glibc/linuxthreads/specific.c,v
> retrieving revision 1.1.1.5
> diff -u -p -r1.1.1.5 specific.c
> --- specific.c	1998/12/01 16:22:30	1.1.1.5
> +++ specific.c	1999/03/17 03:30:10
> @@ -80,7 +80,7 @@ int pthread_key_delete(pthread_key_t key
>    idx2nd = key % PTHREAD_KEY_2NDLEVEL_SIZE;
>    th = self;
>    do {
> -    if (th->p_specific[idx1st] != NULL)
> +    if (!th->p_terminated && th->p_specific[idx1st] != NULL)
>        th->p_specific[idx1st][idx2nd] = NULL;
>      th = th->p_nextlive;
>    } while (th != self);

Forgive my possible ignorance, but if on an future SMP system, you can
have two threads running on different CPUs at the same time in a
shared memory system, and there is no `other' locking, the above seems
like it needs a lock around it.