Xcode – Swift concurrency warning. The compiler warns that my concurrent code will not compile in Swift 6 but all the variables are local

I believe that Sweeper answered your question: To let the compiler know that you have manually synchronized your access to your buffer, you would either use nonisolated(unsafe) var, or wrap it in a type that is designated as @unchecked Sendable.

A few observations, each subsequent alternative offering a further performance benefit:

1. There is no point in using a concurrent queue for synchronization if all of your calls are going to use barriers. If you wanted to use GCD for synchronization, what you’ve got here is equivalent to a serial queue.

2. Personally, I would use a lock: NSLock is simple and faster than GCD queues, OSAllocatedUnfairLock is even faster and eliminates the nonisolated(unsafe) var and/or @unchecked Sendable workarounds:

   import os.lock
   
   nonisolated func processParallel(backingImage: [UInt8]) async -> [UInt8] {
       await withCheckedContinuation { continuation in
           let count = backingImage.count
           let lock = OSAllocatedUnfairLock(initialState: [UInt8](repeating: 0, count: count))
   
           DispatchQueue.concurrentPerform(iterations: count) { index in
               let processedValue = UInt8(UInt16(backingImage[index]) * 2 % 256) // Example processing
               lock.withLock { buffer in
                   buffer[index] = processedValue
               }
           }
           lock.withLock { buffer in
               continuation.resume(returning: buffer)
           }
       }
   }
   

3. Alternatively, you can use a UnsafeMutableBufferPointer<UInt8>, and because your algorithm guarantees that no individual byte in that buffer is mutated in parallel, no synchronization is needed at all:

   nonisolated func processParallel(backingImage: [UInt8]) async -> [UInt8] {
       await withCheckedContinuation { continuation in
           let count = backingImage.count
           nonisolated(unsafe) let buffer = UnsafeMutableBufferPointer<UInt8>.allocate(capacity: count)
           defer { buffer.deallocate() }
   
           DispatchQueue.concurrentPerform(iterations: count) { index in
               let processedValue = UInt8(UInt16(backingImage[index]) * 2 % 256) // Example processing
               buffer[index] = processedValue
           }
           continuation.resume(returning: [UInt8](buffer))
       }
   }
   

   Note, this technique of dropping the synchronization cannot be done with Array<UInt8> (aka, [UInt8]) or Data types, but you can get away with it when using Unsafe[Mutable][Raw][Buffer]Pointer types.

4. You should “stride”. E.g., let’s imaging that your buffer has 10m bytes, you really do not want to do 10m context switches. Instead, have each iteration process 100k or 1m points. This will have a significant performance impact:

   nonisolated func processStriding(backingImage: [UInt8]) async -> [UInt8] {
       await withCheckedContinuation { continuation in
           let count = backingImage.count
           nonisolated(unsafe) let buffer = UnsafeMutableBufferPointer<UInt8>.allocate(capacity: count)
           defer { buffer.deallocate() }
   
           let stride = 1_000_000
           var (iterations, remainder) = count.quotientAndRemainder(dividingBy: stride)
           if remainder != 0 {
               iterations += 1
           }
   
           DispatchQueue.concurrentPerform(iterations: iterations) { i in
               let start = i * stride
               let end = min(start + stride, count)
               for index in start ..< end {
                   let processedValue = UInt8(UInt16(backingImage[index]) * 2 % 256) // Example processing
                   buffer[index] = processedValue
               }
           }
           continuation.resume(returning: [UInt8](buffer))
       }
   }
   

   You will want to play around with different striding factors and experimentally verify which offers the best performance.

5. A minor point, but your question does not share where you got this [UInt8] “image” to start with, but if you, for example, extracted it from a CGImage data provider, you might not want to use [UInt8] at all, but just access the CGBitmapContextGetData data directly (or whatever) and avoid these high-level data types altogether. Manipulating native image buffers results in more complex code, but it frequently will be far more performant than round-tripping through [UInt8].

6. As a final observation, before you lose too much sleep optimizing parallel calculations on the CPU, there are many custom frameworks for image processing (e.g., the Accelerate, CoreImage, Vision, etc.). These offer a dizzying array of specialized, highly-optimized algorithms, and many are GPU-based.

   So, before you go too far in writing your own parallelized CPU-based algorithms, I would suggest seeing if there is an existing framework that can be leveraged to better solve your specific business problem. And I would not dwell on the simplified “multiply by 2” sort of problem, but focus on the actual business problem you are trying to solve, as the implementations might be radically different from each other. E.g., one sort of approach might be relevant if you really want to multiply every byte by some scalar, but if you are planning on something more substantive, all the work in the “vector/matrix times scalar” details becomes irrelevant.

   This obviously is far beyond the scope of this question, but just a word of advice.