So take a look at your method:
void DoSomethingToImage(int[,] image) { for (int i = 0; i < width; i++) { for (int j = 0; j < height; j++) { image[i, j] = 255; } } }
Is it asynchronous? Obviously not. This is just processor related work that will delay the processor a bit. Thus, it is not very good to do asynchronous by itself. It should be run synchronously.
What if you consume this from the asynchronous part of the application? Of course, you do not want the user interface to be blocked because you are repeating a lot of pixels. So the solution is to load the work into another thread. You do this with Task.Run :
await Task.Run(() => DoSomethingToImage(image));
So you should write this when you call the DoSomethingToImage method from an asynchronous method. Now, if you use this method only in asynchronous contexts, you can argue that it makes sense to move Task.Run to a function:
Task DoSomethingToImageAsync(int[,] image) { return Task.Run(() => { … }); }
Is that a good idea? Generally not, because now you are making the method asynchronous when it is not actually there. All he does is create a new thread that does this work and then waits for the thread to finish. So, now you hide this part, and also make a method that performs highly synchronous work, decide that the thread should be started. This is rarely a good idea. And there is nothing wrong with maintaining a method as it is, showing that it is synchronous, and making the calling code responsible for deciding how that code should be run.
If I have an algorithm written in a function that has so far been synchronous, how can I convert it for asynchronous use?
So, getting back to your actual question, this is actually hard to answer. The answer is probably: "It depends."
If the method works with the CPU, you better not synchronize it and let the calling code decide how to start it. If you are primarily involved in I / O, where you interact with other interfaces (network, file system, etc.), then this is a good candidate for its asynchrony, especially considering that many of these interfaces already offer asynchronous ways of interacting with them.
One final note about your "asynchronous need here?" the question is in your code: you need the async keyword when you want to use await inside it. The mere presence of the async does not make the method asynchronous, though (even the return type does not indicate this).