OK - I've recoded this to take out the max call stack depth problem (no more than 1 call depth), but there is still an issue.

I've finally figured this out - I was using a do while loop to control the iterations - I switched this to a for loop with a break statement - this solved all the issues. Not sure exactly what is the reason, but there must be something that metal does with a do while loop that uses more resources.

Thank you very much - that solved the problem. I hadn't come across autoreleasepool before - reading up on this, this needs to be used if objects are created based on older (Objective-C based) frameworks. Thank you again. Colin

Thank you very much for your reply. You are right on both counts - I originally had the ! since it was implemented as a "while" loop, and I forgot to change this when I altered to a "for" loop. As you predicted, however, it still doesn't work - I still have a race condition on the threads where the locks appear to be set, and some threads never get to set the lock. I can't see how to do this inside Metal - fences seem to work between encoders, rather than inside a kernel. Is this a current limitation of Metal or are there techniques for solving this? Thank you again, Colin

I found these symbols appears in Xcode: METAL_MEMORY_ORDER_ACQUIRE METAL_MEMORY_ORDER_RELEASE Any idea how to use these anyone? I couldn't find them in any of the metal include files, though METAL_MEMORY_ORDER_RELAXED was defined in metal_types. Thank you, Colin