* swapcontext happening on different threads
@ 2024-03-12 7:24 Andrew Pinski
2024-03-12 12:48 ` Szabolcs Nagy
2024-03-12 13:47 ` Florian Weimer
0 siblings, 2 replies; 3+ messages in thread
From: Andrew Pinski @ 2024-03-12 7:24 UTC (permalink / raw)
To: GNU C Library
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: swapcontext happening on different threads
2024-03-12 7:24 swapcontext happening on different threads Andrew Pinski
@ 2024-03-12 12:48 ` Szabolcs Nagy
2024-03-12 13:47 ` Florian Weimer
1 sibling, 0 replies; 3+ messages in thread
From: Szabolcs Nagy @ 2024-03-12 12:48 UTC (permalink / raw)
To: Andrew Pinski, GNU C Library
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)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: swapcontext happening on different threads
2024-03-12 7:24 swapcontext happening on different threads Andrew Pinski
2024-03-12 12:48 ` Szabolcs Nagy
@ 2024-03-12 13:47 ` Florian Weimer
1 sibling, 0 replies; 3+ messages in thread
From: Florian Weimer @ 2024-03-12 13:47 UTC (permalink / raw)
To: Andrew Pinski; +Cc: GNU C Library
* 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-03-12 13:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-12 7:24 swapcontext happening on different threads Andrew Pinski
2024-03-12 12:48 ` Szabolcs Nagy
2024-03-12 13:47 ` Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).