Library not suitable for multithreaded environment

[Mas313]

Hi,
I ran multiple receivers total 4 in 4 threads, with gmskframesyn_execute to demodulate and decode data but no luck. If I ran one thread then results are ok.
Even without a thread if downconverted buffers are passed to gmskframesyn_execute() in series then also library unable to decode anything.
In this case also only one single gmskframesyn_execute() is able to decode with rest commented out.
It means gmskframesyn_execute() is internally not thread safe or else I am missing something.
I did something like this:

gmskframesyn_execute(fs1,shifted1,numSamples);
gmskframesyn_execute(fs2,shifted2,numSamples);
gmskframesyn_execute(fs3,shifted3,numSamples);
gmskframesyn_execute(fs4,shifted4,numSamples);

The callbacks are seperate for each element.
Thanks for the time.

[JayKickliter]

I don't see anything in the source referencing globals or anything that would make gmskframesync_execute non-reentrant. I suggest running your threaded test case with TSan

[jgaeddert]

That's right; the only thing that makes liquid-dsp non thread-safe (AFAIK) is use of the random number generator in the standard c library. Are the different "shifted" inputs with different time offsets? It's hard to know what the source of the problem you're encountering without further detail.

[Mas313]

No, i have in all receivers used nco to downcovert to desired transmitter frequency, each receiver to receive respective only one transmission. There is no use of random number generation.