swapcontext happening on different threads

swapcontext happening on different threads

[Andrew Pinski]

Reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65712 .

I am not 100% sure if this is a valid thing to do.
But take the code in the referenced GCC bug report. Currently since
pthread_self is marked as const, if you swap to a different context
and then have that context be swapped on a different thread, you
might/will get the old value of pthread_self in some cases.

Is this well defined or is this a corner case that was not expected. I
don't see anywhere in the older versions of POSIX that explain what
would happen if you do that. And glibc's documentation does not talk
about this case either.

It would be useful if the documentation talked about this either way.

Thanks,
Andrew Pinski

Re: swapcontext happening on different threads

[Szabolcs Nagy]

The 03/12/2024 00:24, Andrew Pinski wrote:
> Reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65712 .
> 
> I am not 100% sure if this is a valid thing to do.
> But take the code in the referenced GCC bug report. Currently since
> pthread_self is marked as const, if you swap to a different context
> and then have that context be swapped on a different thread, you
> might/will get the old value of pthread_self in some cases.
> 
> Is this well defined or is this a corner case that was not expected. I
> don't see anywhere in the older versions of POSIX that explain what
> would happen if you do that. And glibc's documentation does not talk
> about this case either.
> 
> It would be useful if the documentation talked about this either way.

yeah.

my view is that resuming on a different thread is invalid.
(tls address or other thread specific state cached on the
stack is broken).

there are known users who switch between threads via swapcontext,
i think they are on their own to ensure things work since they
are in undefined land (maybe the compiler could help with
appropriate barriers).

otoh const pthread_self is theoretically wrong even without
swapcontext breaking it: the compiler can cache const func
output into a per-process global variable as far as i can
tell. (iirc there were bugzilla discussions before that
attribute const should not allow exception return or different
return values in different threads. btw this affects
__errno_location too in glibc)

Re: swapcontext happening on different threads

[Florian Weimer]

* Andrew Pinski:

> Reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65712 .
>
> I am not 100% sure if this is a valid thing to do.
> But take the code in the referenced GCC bug report. Currently since
> pthread_self is marked as const, if you swap to a different context
> and then have that context be swapped on a different thread, you
> might/will get the old value of pthread_self in some cases.
>
> Is this well defined or is this a corner case that was not expected. I
> don't see anywhere in the older versions of POSIX that explain what
> would happen if you do that. And glibc's documentation does not talk
> about this case either.
>
> It would be useful if the documentation talked about this either way.

There have been passed discussions about this on the gcc list, for other
stackful coroutine implementations.  QEMU in particular needs a way to
implement a barrier for thread-local variable optimizations.  This is
not just about const functions like pthread_self or __errno_location, it
impacts GCC code generation for TLS variable access as well.

  Disabling TLS address caching to help QEMU on GNU/Linux
  <https://inbox.sourceware.org/gcc/87im15qbp3.fsf@oldenburg.str.redhat.com/>

I'm sure the QEMU developers would still appreciate explict TLS address
barriers in GCC.  As part of this, maybe we can get a replacement
function attribute to replace const for those functions.

Thanks,
Florian