Forums

does FFTW break when subjected to multiple simultaneous requests?

Started by all4dsp March 15, 2012
Anyone know if multiple simultaneous requests to (the same instance of)
FFTW are made, will FFTW either:

(1) simply serialize these requests (e.g. perform one right after the
other), thereby completing all requests given sufficient time, or

(2) crash or otherwise be unhappy?

If (1) occurs, then all is well. But if (2) occurs, then I need to manage
the requests into a queue and make sure FFTW is exposed to only one request
at a time. Anyone have experience with this?

A third possibility might be that if a routine calling FFTW is run multiple
times simultaneously then multiple instances of FFTW are created, one for
each request -- but I believe my previous post below showed FFTW doesn't
work that way.  

http://www.dsprelated.com/showmessage/155058/1.php
all4dsp wrote:

> Anyone know if multiple simultaneous requests to (the same instance of) > FFTW are made, will FFTW either: > > (1) simply serialize these requests (e.g. perform one right after the > other), thereby completing all requests given sufficient time, or > > (2) crash or otherwise be unhappy? > [..]
Have you read this section of the manual? http://www.fftw.org/fftw2_doc/fftw_4.html bye Andreas -- Andreas H�nnebeck | email: acmh@gmx.de ----- privat ---- | www : http://www.huennebeck-online.de Fax/Anrufbeantworter: 0721/151-284301 GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc
>Have you read this section of the manual? >http://www.fftw.org/fftw2_doc/fftw_4.html > >bye >Andreas
Yes. It's my understanding when the document speaks of "Parallel FFTW" (the section your link points to), it deals with the options available in FFTW to process a single DFT (or IDFT) request faster by parallelizing this request using (1) multiple threads, (2) MPI, or (3) Cilk. Correct me if I'm wrong, but this section does not address (nor anywhere else I could find) the situation where simultaneous requests are made for FFTW to perform different DFTs (or IDFTs), where each DFT is completely independent and unrelated from all other DFTs.
On Thu, 15 Mar 2012 21:59:25 -0500, all4dsp wrote:

> Anyone know if multiple simultaneous requests to (the same instance of) > FFTW are made, will FFTW either: > > (1) simply serialize these requests (e.g. perform one right after the > other), thereby completing all requests given sufficient time, or > > (2) crash or otherwise be unhappy? > > If (1) occurs, then all is well. But if (2) occurs, then I need to > manage the requests into a queue and make sure FFTW is exposed to only > one request at a time. Anyone have experience with this? > > A third possibility might be that if a routine calling FFTW is run > multiple times simultaneously then multiple instances of FFTW are > created, one for each request -- but I believe my previous post below > showed FFTW doesn't work that way. > > http://www.dsprelated.com/showmessage/155058/1.php
If it helps your Google-Fu, you are asking "Is FFTW thread safe?". At least -- I think that's what you're asking. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
all4dsp wrote:

>>Have you read this section of the manual? >>http://www.fftw.org/fftw2_doc/fftw_4.html > > Yes. It's my understanding when the document speaks of "Parallel FFTW" > (the section your link points to), it deals with the options available in > FFTW to process a single DFT (or IDFT) request faster by parallelizing > this request using (1) multiple threads, (2) MPI, or (3) Cilk. > > Correct me if I'm wrong, but this section does not address (nor anywhere > else I could find) the situation where simultaneous requests are made for > FFTW to perform different DFTs (or IDFTs), where each DFT is completely > independent and unrelated from all other DFTs.
The second sentence (in parentheses) of the first paragraph links to this scenario: http://www.fftw.org/fftw2_doc/fftw_3.html#SEC46 bye Andreas -- Andreas H�nnebeck | email: acmh@gmx.de ----- privat ---- | www : http://www.huennebeck-online.de Fax/Anrufbeantworter: 0721/151-284301 GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc
>all4dsp wrote: > >>>Have you read this section of the manual? >>>http://www.fftw.org/fftw2_doc/fftw_4.html >> >> Yes. It's my understanding when the document speaks of "Parallel FFTW" >> (the section your link points to), it deals with the options available
in
>> FFTW to process a single DFT (or IDFT) request faster by parallelizing >> this request using (1) multiple threads, (2) MPI, or (3) Cilk. >> >> Correct me if I'm wrong, but this section does not address (nor
anywhere
>> else I could find) the situation where simultaneous requests are made
for
>> FFTW to perform different DFTs (or IDFTs), where each DFT is completely >> independent and unrelated from all other DFTs. > >The second sentence (in parentheses) of the first paragraph links to this
scenario:
>http://www.fftw.org/fftw2_doc/fftw_3.html#SEC46 > >bye >Andreas >-- >Andreas H�nnebeck | email: acmh@gmx.de >----- privat ---- | www : http://www.huennebeck-online.de >Fax/Anrufbeantworter: 0721/151-284301 >GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc >PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc >
Hi Andreas, I'm not sure what you're referring to by "The second sentence (in parentheses) of the first paragraph...". Are you referring to this?
>> Correct me if I'm wrong, but this section does not address (nor
anywhere
>> else I could find) the situation where simultaneous requests are made
for
>> FFTW to perform different DFTs (or IDFTs), where each DFT is completely >> independent and unrelated from all other DFTs.
If so, I'm not seeing the connection with the link you provided. I tend to agree with Tim's comment regarding thread safety. What do you think?

"all4dsp"  wrote in message 
news:squdnRm_dbdDR_rSnZ2dnUVZ_uOdnZ2d@giganews.com...

>all4dsp wrote: > >>>Have you read this section of the manual? >>>http://www.fftw.org/fftw2_doc/fftw_4.html >> >> Yes. It's my understanding when the document speaks of "Parallel FFTW" >> (the section your link points to), it deals with the options available
in
>> FFTW to process a single DFT (or IDFT) request faster by parallelizing >> this request using (1) multiple threads, (2) MPI, or (3) Cilk. >> >> Correct me if I'm wrong, but this section does not address (nor
anywhere
>> else I could find) the situation where simultaneous requests are made
for
>> FFTW to perform different DFTs (or IDFTs), where each DFT is completely >> independent and unrelated from all other DFTs. > >The second sentence (in parentheses) of the first paragraph links to this
scenario:
>http://www.fftw.org/fftw2_doc/fftw_3.html#SEC46 > >bye >Andreas >-- >Andreas H�nnebeck | email: acmh@gmx.de >----- privat ---- | www : http://www.huennebeck-online.de >Fax/Anrufbeantworter: 0721/151-284301 >GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc >PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc >
Hi Andreas, I'm not sure what you're referring to by "The second sentence (in parentheses) of the first paragraph...". Are you referring to this?
>> Correct me if I'm wrong, but this section does not address (nor
anywhere
>> else I could find) the situation where simultaneous requests are made
for
>> FFTW to perform different DFTs (or IDFTs), where each DFT is completely >> independent and unrelated from all other DFTs.
If so, I'm not seeing the connection with the link you provided. I tend to agree with Tim's comment regarding thread safety. What do you think? Perhaps a difference in web browsers. The section Andreas is referring to is called "Thread Safety" and it appeared near the bottom of the page when I followed his link using I.E> Best wishes, --Phil Martel
> >Perhaps a difference in web browsers. The section Andreas is referring to
>is called "Thread Safety" and it appeared near the bottom of the page when
I
>followed his link using I.E> > > Best wishes, > --Phil Martel > >
Yes, thanks Phil! I think all the commenters are in agreement then. It's documented under thread safety.
> >Perhaps a difference in web browsers. The section Andreas is referring to
>is called "Thread Safety" and it appeared near the bottom of the page when
I
>followed his link using I.E> > > Best wishes, > --Phil Martel > >
Yes, thanks Phil! I think all the commenters are in agreement then. It's documented under thread safety.