[PATCH] D32782: Add pthread_self function prototype and make it speculatable.

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D32782#760320, @davide wrote:

> In https://reviews.llvm.org/D32782#760312, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D32782#760311, @davide wrote:
> >
> > > In https://reviews.llvm.org/D32782#760309, @hfinkel wrote:
> > >
> > > > In https://reviews.llvm.org/D32782#760304, @davide wrote:
> > > >
> > > > > OK, I think I found out the cause. I guess this patch was wrong, my bad.
> > > > >  GCC doesn't do anything special with `pthread_self` per-se.
> > > > >  What GCC does is speculating the `glibc` implementation of `pthread_self` is declared with `__attribute__(const)`.
> > > > >  The semantic of the attribute is that of "The const attribute is specified as asserting that the function does not examine any data except the arguments. " [1]
> > > > >  If the function has no arguments, it has to return the same value every time.
> > > > >
> > > > > Therefore, it speculates.
> > > > >  I think that other libc implementation are free to not declare pthread_self with that attribute. In fact, from what I can see, the FreeBSD version doesn't use that argument.
> > > > >  In other words, I don't think we're allowed to do anything with `pthread_self()` in general as POSIX specifies weaks guarantees.
> > > >
> > > >
> > > > So there a general implication we can implement: `__attribute__(const)`. + zero arguments == speculatable?
> > >
> > >
> > > I'm not sure if that's the exact recipe, but yes, it seems to be on the right path.
> > >
> > > > Also, I fail to see how it would not be safe to tread pthread_self as speculatable? Same for getpid.
> > > > 
> > > > The standard says that the call always succeeds and always returns the thread id. The thread ids are opaque, and I can imagine there being multiple "self" values (pthread_equal would just return true for all of them), thus making pthread_self non-const. However, I can think of no reason why an implementation would do this, don't know of any that do, the behavior would only be observable via some non-standard interface, and I'm happy to cross that bridge if we come to it.
> > >
> > > I don't understand the bit about `getpid()`. In that case forking actually could change the value and you might end up in trouble if you rely on that to write temporary directories (as it's generally done).
> >
> >
> > Oh. You're right. Also, that seems to also rule out this as well. fork() could also change the value of pthread_self() I'd imagine.
>
>
> It's slightly different, at least in my opinion.
>  `getpid()` returns a `pid_t`.
>
> `pid_t` is defined to be an integer type, although POSIX doesn't put any restrictions on the size.
>  http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html
>
> `glibc` (and FreeBSD `libc`) decide to make it an `int`. People know it's an integer and use as such.
>
> On the other hand, `pthread_t` is considered to be an opaque type. It can be an integer/a struct/you name it.
>  In fact, this completely opaque implementation detail wildly varies across implementations (for LinuxThreads, it's an integer, for NPTL, a pointer).
>  http://man7.org/linux/man-pages/man3/pthread_self.3.html
>  Linux also documents that using pthread_t in anything that's not pthread calls results in an unspecified behaviour, while `pid_t` can be used freely.
>
> So, it's not quite the same, but it's still debatable whether the transformation should be performed or not.


I understand all of this, but the underlying issue is still the same: you can't, in general, move the call past fork(). I see no reason that pthread_equal on the pre-fork and post-fork values would always return true (although this seems to be the case on Linux, even if you fork from a child thread).


Repository:
  rL LLVM

https://reviews.llvm.org/D32782