You signed in with another tab or window. Re
10000
load to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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?
Activity
marcusmueller commentedon Aug 21, 2017
This is not a bug-tracker issue, but a question. It's usually not good style to post such on an issue tracker.
mcourteaux commentedon Aug 23, 2017
Let's issue-ify it; the documentation doesn't mention thread safety.
linkotec commentedon Aug 23, 2017
Most
ffts_plan_tobjects are using internal working buffer, which means that they are not thread safe. At the moment only plans generated byffts_init_1dwith power of two sizes are thread-safe.To make all plans thread-safe we have to modify
ffts_executeto allow passing optional working buffer. At the same timeffts_plan_tshould 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 commentedon Aug 23, 2017
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_tis still in use or not. Things I've thought about:fft_plant_tbe quickly copyable?ffts_execute_mtfunction that takes in a working buffer. Something like:Do you think it is easy to implement something like this?