Is FFTS thread-safe?

[mcourteaux]

Can I use a single ffts_plan_t object multiple times simultaneously from different threads using ffts_execute()?

[marcusmueller]

This is not a bug-tracker issue, but a question. It's usually not good style to post such on an issue tracker.

[mcourteaux]

Let's issue-ify it; the documentation doesn't mention thread safety.

[linkotec]

Most ffts_plan_t objects are using internal working buffer, which means that they are not thread safe. At the moment only plans generated by ffts_init_1d with power of two sizes are thread-safe.

To make all plans thread-safe we have to modify ffts_execute to allow passing optional working buffer. At the same time ffts_plan_t should be converted to a smart pointer that retains shared ownership of plan. And if we add mutexes/locks, we can safely use plan from multiple threads; one thread at a time if working buffer isn't provided.

[mcourteaux]

I would vote for minimal impact changes: no locks/mutexes. People using this library are advanced users, and can should be able to implement things correctly, without the library double checking everything you do. Same goes for the smart pointer idea. This is a C library, simply let the user deal with keeping track of wether a ffts_plan_t is still in use or not. Things I've thought about:

• Maybe we could use a prototype design pattern? Can a fft_plant_t be quickly copyable?
• A function that tells you how big the working buffer should be, and a second ffts_execute_mt function that takes in a working buffer. Something like:

ffts_plan_t *plan = ffts_init_2d(...);

// single threaded:
ffts_execute(plan, in, out);

// multi threaded:
size_t working_buffer_size = ffts_working_buffer_size(plan);
float *working_buffer = (float*) _mm_malloc(32, sizeof(float) * working_buffer_size);
ffts_execute_mt(plan, in, out, working_buffer);

Do you think it is easy to implement something like this?