FreeBSD pthread_equal "bug"

[Kern Sibbald]

On Wed, 2003-06-04 at 17:30, Daniel Eischen wrote:
> On 4 Jun 2003, Kern Sibbald wrote:
> > Hello,
> > 
> > I've run into what I consider a bug in the FreeBSD 
> > implementation of pthreads and pthread_equal() in
> > particular.  Basically, pthread_equal() will return
> > true even if it is not the same thread.  This can occur
> > when one thread dies and another one starts. The second
> > thread then takes on the exact identity of the the
> > first thread, and pthread_equal() returns true for a
> > case where it is a different thread.  You may argue
> > that the first thread is dead so its thread id is no
> > longer valid. True, but think about how Unix would
> > work if every process started up with the process
> > id of the last process to exit.
> 
> Process id's can wrap around so it can eventually happen.

Yes, true. However, on Solaris and Linux, it takes a long time,
for the pthread_id to wrap around, and on FreeBSD it happens in
microseconds.

> 
> This is a bug in the application; the implementation is allowed
> to reuse thread id's and there are enough interfaces for an
> application to tell when a thread terminates (pthread_join).

I'm not sure what the POSIX specification says, 
if I were programming it, I would not be content 
with the FreeBSD current implementation especially
considering that both Solaris and Linux do it "correctly".


> Perhaps our use of thread id's could be changes so that they
> were cached at the end of the free thread list, but cacheing
> them at the front seems to highlight bad applications, so
> that's a bonus ;-)

This bug does not highlight bad applications because most
programmers will reasonably expect that pthread_equal() will
not be the same for two different threads. It took me 
a long time to find this problem because I just could not
imagine that pthread_equal() was not "working". 
This problem is extremely subtle and is likely to cause 
unsuspecting applications long months of bizarre
behavior. 

Fix it or not, that is your choice. Now that I know
that you don't handle it as I would suspect I can code
around it.