FreeBSD pthread_equal "bug"

[Kern Sibbald]

Hello,

Yes, it is evident that no matter what one does at
some point the thread id will wrap around -- unless
you use a 64 bit counter. My program wouldn't have had
any problems if it wrapped around some "reasonable" time
later, but in fact, it "wrapped" on the very next thread.

I can see that I was wrong to classify the FreeBSD
as a bug, but it would be valid to say that the FreeBSD
implementation is not as "robust" as the spec would
permit (or advise). Please see:

   http://www.opengroup.org/onlinepubs/007904975/toc.htm

under "Rationale", the view they express is what I consider
a preferred or more robust implementation "additional
flexibility and robustness" ...

I don't quite understand your point about locking up ld.so,
probably because I am not subscribed to the list, and it
isn't worth your time to explain it, but I certainly would
not advocate any change that destabilizes something.

On the other hand, a little loss of performance is a 
good thing if it helps applications run better and/or 
detect their bugs.

As I said, I leave it to you guys to decide what to
do or not to do. I know what I did wrong and have
long ago fixed it

Best regards,

Kern

On Thu, 2003-06-05 at 14:01, Terry Lambert wrote:
> Kern Sibbald wrote:
> > > 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".
> 
> For some number of intervening threads less than 30,000.
> 
> 
> > 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 is a statistical expectation, at best.  Technically,
> you should avoid anything that makes only statistical
> guarantees.
> 
> For example, it's possible to run without memory protection
> through address space separation: what you do is just make
> sure your physical memory size statistically small compared
> to your available address space; for example, say I have 4G
> of physical RAM, and I have a 64 bit processor.  The chance
> of me "guessing" a valid page without faulting is 1:2^32,
> so I don't "need" to enforce address space separation, and
> I avoid all sorts of TLB shootdowns and protection domain
> crossing, etc.
> 
> Comparatively, your protection against a failure with the
> pthread_equal() call on the systems you are using as an
> example of "correct" is less than 1:2^15.
> 
> This example is particularly apt, since threads share a
> process address space.
> 
> 
> > This problem is extremely subtle and is likely to cause
> > unsuspecting applications long months of bizarre
> > behavior.
> 
> Yes.  This is the real problem: application expectations.
> 
> As I implied in my previous message, you have to draw a
> firm line between "application expectations" and "strict
> conformance of applications to the standard".  There are
> already several compromises in FreeBSD's implementations
> for applications expectations; "in for a penny, in for a
> pound".
> 
> 
> > 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.
> 
> IMO, a request to "fix" this (provide an implementation
> kludge that will keep applications happy) is a lot more
> reasonable than locking up ld.so in contravention of the
> SUSv2 Chapter 12.  As you point out, all it would take
> is the addition of a generation count to the pthreads
> structures; if they are type-stable enough to reuse the
> same address, then a generation count is not unreasonable,
> and if they aren't type-stable enough, then it's not a
> problem in the first place (it's just your particular
> application has degenerate behaviour in memory reuse).
> 
> -- Terry