search

jgaeddert / liquid-dsp

digital signal processing library for software-defined radios
http://liquidsdr.org
MIT License
1.9k stars 443 forks source link

Library not suitable for multithreaded environment #380

Open Mas313 opened 2 months ago

Mas313 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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.