Not lock-free

[WonderfulVoid]

"Even worse, if a writer holding an index crashes before committing, then the corresponding reader will never succeed in reading one element even if other writer has completed a write operation. This is the reason why WFMPMC is not strict wait-free."
Well, with this behaviour it is not even lock-free as lock-freedom requires system-wide progress (some thread must make progress) even if one thread fails or blocks.

With loops like this: "while((data = getWritable(idx)) == nullptr);", it is actually blocking. Essentially, each individual slot is protected by its own lock (which allows for alternating enqueues and dequeues). Any thread that continues to enqueue/dequeue objects will eventually attempt to access all slots, including any slot that is blocked.

[MengRao]

I didn't say it's lock-free. But it's non-blocking: you can change to "while((data = getWritable(idx)) == nullptr) { do_other_work(); } ".

[WonderfulVoid]

You wrote "not strict wait-free" which I interpreted (I confess) as a claim that it then was second best, i.e. lock-free. Wait-free > lock-free > non-blocking > blocking.

With your definition of non-blocking, basically all blocking algorithms can be made non-blocking, just add user-defined callbacks which are invoked when waiting for other threads. I think few people will agree with such a definition.

From Java concurrency in practice (Brian Goetz & co):
"An algorithm is called nonblocking if failure or suspension of any thread cannot cause failure or suspension of another thread".

Take a look at a lock-free ring buffer here:
https://github.com/ARM-software/progress64/blob/master/src/p64_lfring.c
The design has been tested with up to 8 threads but I still need to do some more verification.