does FFTW break when subjected to multiple simultaneous requests?

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.