FreeBSD pthread_equal "bug"

Kern Sibbald kern at sibbald.com
Wed Jun 4 07:15:28 PDT 2003


Hello,

I doubt that this is an accident on Solaris and Linux.
They are both excellent implementations (though different)
of pthreads, and it is very clear from the values contained
that they are not simple memory addresses and are designed
to be unique. How they get to their internal structures I
don't know and probably it is a few cycles faster than
FreeBSD, but it makes pthread_equal() work correctly on
their systems.

I can say that their numbers are unique over a very large
number of threads, and they repeat perfectly for each
execution of the program so it isn't likely to be anything
left to chance.

See my notes below:

On Wed, 2003-06-04 at 15:52, Mike Makonnen wrote:
> >From the new linux NPTL:
> >From the new linux NPTL:
> =================
> typedef struct __opaque_pthread *pthread_t;
> int
> __pthread_equal (thread1, thread2)
>      pthread_t thread1;
>      pthread_t thread2;
> {
>   return thread1 == thread2;
> }
> strong_alias (__pthread_equal, pthread_equal)
> 
> 
> >From FreeBSD's libc_r implementation:
> ==========================
> typedef struct  pthread                 *pthread_t;
> __weak_reference(_pthread_equal, pthread_equal);
> 
> int
> _pthread_equal(pthread_t t1, pthread_t t2)
> {
>         /* Compare the two thread pointers: */
>         return (t1 == t2);
> }
> 
> In both implementations pthread_t is a pointer to a memory location.
> So, your inability to reproduce this on Linux is probably an accident and not an
> intentional feature.
> 
> If the two threads (i.e. the dead one and the new one point to the same memory
> location using unique id's is not going to solve the problem because both
> pointers will be pointing to the same structure (and therefore the same unique
> id, even though it will be a different id after the second thread is created).
> 
> The only fool-proof way to do this is to make pthread_t a proper structure
> containing a unique id and a pointer to a thread structure, but that would mean
> passing a structure on the stack (which is not necessarily bad in itself,
> but means someone would have to go through all the threads libraries and
> modify appropriately). 

On Linux, the above is not true. The pthread_id is :

typedef unsigned long int pthread_t;


> On the other hand I may be mistaken and there may be an easy way to achieve
> this :-)

Yup, there must be judging by the above.

As previously mentioned, I'm not convinced this is something urgent,
but I am convinced it is a bug.  However, it certainly bit me and
took me a bit to figure out.

Best regards,

Kern





More information about the freebsd-threads mailing list