On Thursday, 27 July 2023 at 21:31:02 UTC, Jonathan M Davis wrote:
Now, as to what's happening in your code that's causing
segfaults, the most likely culprit would be that you're
accessing the AA without actually having done anything to
prevent other threads from accessing it at the same time (or
your protections were inadequate).
I use a shared Mutex from `core.sync.mutex`.
The AA itself and the `final class` that it's a member of is only
ever accessed by one thread for now.
The code inside that `final class` that accesses the AA is called
by a function from another `final class`, and that other `final
class` is used by multiple threads, but it's fully guarded by
Mutex locks—I haven't had any issues with the millions of
non-atomic reads and writes on its data I've performed from the
two threads. Both objects are "static" (declared at module scope)
if that matters at all.
if the AA were shared, the only sections of code where you
would have to worry about thread-local references escaping
would be in the sections of code where you've cast away shared
after locking the relevant mutex. So, similar to what happens
with @safe and @trusted, using shared allows you to limit the
code that you have to examine to find the problem.
I was told that using `__gshared` is quite a bit faster at
runtime than using `shared`, but I also don't really know
anything concrete about `shared` because the spec is so
incredibly vague about it.
