What is the safe way to generate random number with a known seed using OpenMP?

I am looking for a way to be able to safely generate random numbers in parallel with OpenMP while the input seed is already known. I searched and ended up with OMPRNG. Is there another way expect using a package that I can manually write a code? Also, I would like to mention that I need these random numbers for monto Carlo integration.

In the context of the monte Carlo Simulation you can use rand_r. From this SO Thread one can read:

I think you're looking for rand_r(), which explicitly takes the current RNG state as a parameter. Then each thread should have it's own copy of seed data (whether you want each thread to start off with the same seed or different ones depends on what you're doing, here you want them to be different or you'd get the same row again and again).

This is actually the function used on the parallel implementation of a Monte Carlo Simulation in this SO Thread that actually yield good results. The code from that answer:

int main(void)
{
    double start = omp_get_wtime();
    long points = 1000000000; //....................................... INPUT AVOIDED
    long m = 0;
    unsigned long HAUSNUMERO = 1;
    double DIV1byMAXbyMAX = 1. / RAND_MAX / RAND_MAX;

    int threads = get_nprocs();
    omp_set_num_threads(threads);
    #pragma omp parallel reduction (+: m )
    {
        unsigned int aThreadSpecificSEED_x = HAUSNUMERO + 1 + omp_get_thread_num();
        unsigned int aThreadSpecificSEED_y = HAUSNUMERO - 1 + omp_get_thread_num();
        #pragma omp for nowait
        for(long i = 0; i < points; i++)
        {
            double x = rand_r( &aThreadSpecificSEED_x );
            double y = rand_r( &aThreadSpecificSEED_y );
            m += (1  >= ( x * x + y * y ) * DIV1byMAXbyMAX);
        }
    }
    double end = omp_get_wtime();
    printf("%f\n",end-start);
    printf("Pi is roughly %lf\n", (double) 4*m / (double) points);
}

Quoting from the comment section (Sam Manson):

Might be worth noting that rand_r only has an int for state (i.e. likely 32bits), so the entire space could get exhausted pretty quickly during a large MC run. 128 bits of state seems more reasonable, which would necessitate some other algorithm (e.g. PCG-64 or xoroshiro128)