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:
sliding_fft_impl::work()
|
enter "fft->execute"
spawn thread 1 & spawn thread 2
| |
calculate calculate
| |
+--------v-------+
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.
Greetings,
Marcus
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_size(fft_size)
{
d_fft = new fft::fft_complex (d_fft_size, 1, 2);
set_history(fft_size);
}
sliding_fft_impl::~sliding_fft_impl()
{
delete d_fft;
}
int
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));
d_fft->execute();
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!!
Best,
Mostafa
_______________________________________________
Discuss-gnuradio mailing address@hidden://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio