pcre: remove nthreads constant dependency

[vtjnash]

This appears to be the only remaining place we use the nthreads variable
to pre-initialize a shared array. Let us fix that code pattern now,
since we know globals are already acquire/release.

[tkf]

The implementation itself LGTM.

This appears to be the only remaining place we use the nthreads variable to pre-initialize a shared array. Let us fix that code pattern now,

Why does this code pattern have to be fixed? Using nthreads for "pseudo thread-local storage" is a bad idea for various parallelism patterns like parallel for loops. But I do think there are legit use cases, especially in concurrent data structures where knowing the number of worker threads is beneficial. For example, it's very useful for writing object/memory pools that can be used in generic concurrent programs. On the theory side, I think shared register construction is a good example that shows knowing something like nthreads is useful.

Instead of hard-coding a thread-local storage pattern like this, I think it'd be better to have a thread-local storage API in Base.Threads. Maybe something like

Threads.@local_storage(THREAD_MATCH_CONTEXTS) do
    create_match_context()
end

get_local_match_context() = THREAD_MATCH_CONTEXTS[]

where Threads.@local_storage is a macro instead of a function call so that we can use import-time allocation via __init__ in a private module ¹ as an implementation strategy.

Footnotes

1. Here's an implementation of this strategy I'm using for Recyclers.@global. ↩

[tkf]

I find it scary that we rely on "implicit" atomic ordering of global for code like this. It looks so innocent and the nuance can get lost during refactoring (even though I understand it is unlikely to happen for this part of code). Rather, I think it'd be easier to encode the atomic ordering by doing something like const THREAD_MATCH_CONTEXTS = Threads.Atomic(Ptr{Cvoid}[C_NULL]).

[vtjnash]

Yeah, I am just waiting on #44231 to be able to specify it explicitly. For now, I am okay with relying on the specified behavior implicitly.

[vtjnash]

Instead of hard-coding a thread-local storage pattern like this, I think it'd be better to have a thread-local storage API in Base.Threads. Maybe something like

Threads.@local_storage(THREAD_MATCH_CONTEXTS) do
    create_match_context()
end

get_local_match_context() = THREAD_MATCH_CONTEXTS[]

This sounds like you are preparing to talk us into #35833 😂

[tkf]

I don't consider the discussion on nthreads resolved (ref #44542 (comment)), but I guess that's OK since this PR only changes the implementation to the one robust against future changes in many directions.