use Julia ReentrantLock rather than fftw_make_planner_threadsafe

[stevengj]

Should fix #141. Closes #157.

[vtjnash]

This is a large portion of it, definitely! Though doesn't yet fix the deadlock. While this is a re-entrant lock, we shouldn't ever see it be re-entered from a given thread (whether on the same or a different task) as fftw doesn't like that. However, we might see that some finalizer tries to acquire this lock. To protect against that, the finalizers also need to be delayed until the unlock call here, to ensure that they destroy call doesn't get blocked.

[stevengj]

I don't quite follow you. If a given thread holds the lock and FFTW is busy calling some thread-unsafe routine (e.g. creating or destroying a thread), how could a finalizer concurrently execute fftw_destroy_plan on the same thread?

[stevengj]

I see, so the scenario we are worried about is something like:

1. User starts creating a plan in a thread. Acquires lock.
2. FFTW planner, while exploring different algorithms, calls spawnloop.
3. During Julia spawnloop execution, one of the spawned threads runs GC and tries to destroy an old plan. Deadlocks.

[stevengj]

Maybe when fftwlock is acquired (i.e. whenever islocked(fftwlock) is true), all destroy_plan calls can be deferred to a queue, and @exclusive can flush the queue right before after it releases the lock?

That will get rid of all the business with a timer in #157, and allow garbage collection to function normally most of the time.

[vtjnash]

That sounds great

[stevengj]

Okay, I updated the thread to defer plan destruction while the lock is held.

(The plan-destruction queue itself requires a lock, and the logic of flushing the queue is a bit tricky to avoid deadlocks or race conditions, so I'd appreciate another pair of eyes to double-check my logic.)

[vtjnash]

I think this is on the right track, but may have some of the locked sections in the wrong order so that they don’t do what they are supposed to

[vtjnash]

This seems correct to me.

[stevengj]

Now that I think of it, it should actually be safe to use the regular trylock in maybe_destroy_plan — the FFTW planner is not thread-safe, but re-entrant calls to destroy_plan in the same thread should be fine (as long as we don't call make_planner_thread_safe, which adds an internal mutex lock). (The planner does lots of plan destruction already.)

So, it should be fine to destroy a plan in the thread that acquired the planner lock, even if that occurs during planning.

reverted in b9e0000