On 3/26/23 4:41 PM, ryuukk_ wrote:
On Sunday, 26 March 2023 at 19:08:32 UTC, Steven Schveighoffer wrote:
On 3/26/23 2:07 PM, ryuukk_ wrote:
Hi,
It's common knowledge that accessing tls global is slow
http://david-grs.github.io/tls_performance_overhead_cost_linux/
What i do not understand is the reasoning behind choosing tls global
by default in D
If you know a variable is not `shared`, then you know it can only be
accessed from the current thread. This has huge implications for
thread access.
However, one problem that D has no good solution is passing
thread-local data to another thread (to be owned by the new thread,
and no access in the current thread). That's typically the most common
use case for "shared data".
I haven't explored this use case, that must explain why i find it
surprising, however, i read about other languages too, and they seem to
be explicit whenever they make use of TLS
C, C++, Rust, Zig, Go doesn't do TLS by default for example
If you want to have the type system tell you when a variable is readable
from other threads or not, you need to have *something* to distinguish
them. 99% of all variables are not readable from other threads, so
making that the default seems the right call to me.
I don't know if you have thought through the implications. Start with
the requirement that I need to know by examining the type whether the
value is viewable from multiple threads. Is there a better mechanism
with better defaults? C/C++ is precisely the wrong answer -- just let
the programmer fend for himself. I haven't used the others to know what
their story is.
One possibility is to REQUIRE you to mark module-level and static
variables as one of `__gshared`, `shared`, `immutable`, or `@tls`. I
would be OK with such a change.
I've run into a situation where I want to make a thread local pointer to
shared data, and it's not easy. The only solution I could come up with
is to put it inside a dummy struct with a shared member. Having a `@tls`
storage class would help solve that.
-Steve
