There is the unexported Random.default_rng(), which will return the task local RNG object. If you seed! that, you’ll seed the RNG for that task (not thread!). The thread itself doesn’t have an RNG, but the task that runs on a thread does. That only works in 1.7 though - 1.6 still has one global RNG, so passing them around is a necessity there. In either case, it will be better and easier to maintain later on (e.g. with a new julia version…) when you pass RNG objects around explicitly. It’s not expensive to do so.
To me, if a library that’s relying on RNG doesn’t allow me to pass in an RNG of my own and instead relies on the global RNG, that’s a badly designed library. It prevents me from using the library in all sorts of parallel fashions that require putting in different RNGs.
Sounds like you really want to give an explicitly initialized RNG to each of your jobs instead of relying on the task-local RNG to not change. You don’t necessarily know how the task local RNGs are affected without controlling for that. If you spawn subtasks (e.g. by using the wonderful Tullio.jl and its internal threading, which spawns tasks), that may interfere with the task local RNG in ways you didn’t expect. Passing the RNG you rely on explicitly guards you from that.
What do you really want to compare, what are you testing? Usually people want to (or rather, should imo) test whether an algorithm is indifferent to changes in the stream of random numbers. What you’re describing sounds like you’re trying to find out which changes in parameters (don’t) influence how many times random numbers are needed, which to me seems like an odd thing to measure.
There are a number of threads about the stability of the random number stream, but I’d really recommend rethinking your approach if you rely on the number stream to be 100% the same. Do you have other properties of your job output you could check? Properties that should hold no matter which exact numbers are produced by the random number stream? If so, I recommend checking those instead of trying to control randomness (which kind of defeats the purpose of randomness).