Keep number of threads in a global variable separate from global OMP config

[david-cortes]

ref #4705
ref #6133

This PR changes the recently introduced workaround for getting the number of threads to be a global variable specific to lightgbm instead of modifying the global openmp configuration.

This is a quick workaround (compared to using a variable local to a function call) and doesn't solve the problem for good - for example, if one calls fit in multiple threads, the configs will overwrite each other, but at least they won't conflict with those of other software.

Ideally this new global variable should be thread-local but I see that lightgbm is also compiled with MSVC and I'm not sure if omp's thread-local pragmas are supported for that compiler so I left them out.

[jameslamb]

Thanks for working on this! I generally support this pattern, but leaving a blocking review because I'd like the opportunity to test this.

I have also been working on a similar approach (+ a more permanent solution to LightGBM's various multi-threading issues you've linked) over in my fork, just haven't had time to move it forward as I've been traveling for the last two weeks.

[jameslamb]

I've been testing an approach like this over on my fork (jameslamb#55) and I don't think just having static int in a header here will work.

I found that when I did that, everything that included openmp_wrapper.h got its own copy of that integer, and that therefore updates like this:

LightGBM/src/c_api.cpp

Line 316 in 8ed371c

OMP_SET_NUM_THREADS(config_.num_threads);

did not propagate through everywhere.

[jameslamb]

Closing this, as it was superseded by #6226.

Sorry to do that, but I think it was necessary given the time pressure associated with needing to do a new release to CRAN before they archived {lightgbm} (#6221).

Thanks as always for your help with LightGBM, and for documenting these issues with thread control in #4705 and other discussions.