[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] multi thread fft execution

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] multi thread fft execution
Date: Sat, 25 Oct 2014 14:26:38 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

Hi Mostafa,

>is there any "race" problem between these 2 threads and the work one?
I think you might be confused what the FFT multithreading means here; I hope I can illustrate this. Let's set the FFT multithreading level to two threads:

     enter "fft->execute"

spawn thread 1 & spawn thread 2
      |                |
  calculate               calculate
      |                |
         join threads
    return from "fft->execute"
       continue ::work

The work thread waits for fft->execute to return; there can be no interference while the fft threads run, because at that time, the work thread isn't "active".

>Inj another words, is it possible that this work being called before finishing the fft execution?

no, a single block's work() cannot get called before the previous run of work() has finished. That wouldn't make any sense -- how would the second work now how many input samples it has, if the first one hadn't already consumed?

Your code looks correct. I know I tell you this in almost every discussion on here, but:
Please, tell us what "undesired" means. That would greatly reduce the guesswork for the rest of the mailing list.

Also, sliding FFTs do look like a computational heavy load. What is the application for that? I ask because getting an fft_length FFT for every item increases item/sample rate without giving you (information-theoretically speaking) any advantage over doing one FFT ever fft_length samples.


On 10/25/2014 12:03 PM, Mostafa Alizadeh wrote:
Hi all, 
I have the following c++ code which gets fft by sliding on sample by sample fo the input. 

     * The private constructor
    sliding_fft_impl::sliding_fft_impl(uint fft_size)
      : gr::sync_block("sliding_fft",
              gr::io_signature::make(1, 1, sizeof(gr_complex)),
              gr::io_signature::make(1, 1, fft_size * sizeof(gr_complex))),
        d_fft = new fft::fft_complex (d_fft_size, 1, 2);

        delete d_fft;
    sliding_fft_impl::work(int noutput_items,
			  gr_vector_const_void_star &input_items,
			  gr_vector_void_star &output_items)
        const gr_complex *in = (const gr_complex *) input_items[0];
        gr_complex *out = (gr_complex *) output_items[0];

        memcpy(d_fft->get_inbuf(), in, d_fft_size * sizeof(gr_complex));
        memcpy(out, d_fft->get_outbuf(), d_fft_size * sizeof(gr_complex));

        //delete d_fft;
        return 1;

If I run the fft execution on 2 threads, or more, is there any "race" problem between these 2 threads and the work one? Inj another words, is it possible that this work being called before finishing the fft execution?

If it is so, there will be a race problem because "work" wants to write on d_fft->get_inbuf() while fft execution wants to read from it! 

please help me with this code. I don't know why at the runtime, the data I give at the output aren't desired after a while!!


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]