Sleep task (System.Threading.Tasks)

Thread.Sleep is a synchronous delay. If you want an asynchronous delay then use Task.Delay.

In C# 5, which is at present in beta release, you can simply say

await Task.Delay(whatever);

in an asynchronous method, and the method will automatically pick up where it left off.

If you are not using C# 5 then you can "manually" set whatever code you want to be the continuation of the delay yourself.

When you pass a new TaskScheduler that is from the current synchronization context, you actually telling the task to run on the UI thread. You actually want to do that, so you can update the UI component, however you don't want to sleep on that thread, since it will block.

This is a good example of when .ContinueWith is ideal:

TaskScheduler ui = TaskScheduler.FromCurrentSynchronizationContext();var task = Task.Factory.StartNew(() =>                                     {                                         pic.Image = Properties.Resources.NEXT;                                     },                                 CancellationToken.None,                                 TaskCreationOptions.None,                                 ui);task.ContinueWith(t => Thread.Sleep(1000), TaskScheduler.Default)    .ContinueWith(t =>                      {                          pic.Image = Properties.Resources.Prev;                      }, ui);

EDIT (Removed some stuff and added this):

What happens is that we're blocking the UI thread for only enough time to update pic.Image. By specifying the TaskScheduler, you're telling it what thread to run the task on. It's important to know that the relationship between Tasks and Threads is not 1:1. In fact, you can have 1000 tasks running on relatively few threads, 10 or less even, it all depends on the amount of work each task has. Do not assume each task you create will run on a separate thread. The CLR does a great job of balancing performance automatically for you.

Now, you don't have to use the default TaskScheduler, as you've seen. When you pass the UI TaskScheduler, that is TaskScheduler.FromCurrentSynchronizationContext(), it uses the UI thread instead of the thread pool, as TaskScheduler.Default does.

Keeping this in mind, let's review the code again:

var task = Task.Factory.StartNew(() =>                                     {                                         pic.Image = Properties.Resources.NEXT;                                     },                                 CancellationToken.None,                                 TaskCreationOptions.None,                                 ui);

Here, we're creating and starting a task that will run on the UI thread, that will update the Image property of pic with your resource. While it does this, the UI will be unresponsive. Fortunately, this is a likely a very fast operation, and the user won't even notice.

task.ContinueWith(t => Thread.Sleep(1000), TaskScheduler.Default)    .ContinueWith(t =>                      {                          pic.Image = Properties.Resources.Prev;                      }, ui);

With this code, we're calling the ContinueWith method. It does exactly what it sounds like. It returns a new Task object that will execute the lambda parameter when it runs. It will be started when the task has either completed, faulted or been cancelled. You can control when it will run by passing in TaskContinuationOptions. However, we're also passing a different task scheduler as we did before. This is the default task scheduler that will execute a task on a thread pool thread, thus, NOT blocking the UI. This task could run for hours and your UI will stay responsive (don't let it), because it's a separate thread from the UI thread that you are interacting with.

We've also called ContinueWith on the tasks we've set to run on the default task scheduler. This is the task that will update the image on the UI thread again, since we've passed that same UI task scheduler to the executing task. Once the threadpool task has finished, it will call this one on the UI thread, blocking it for a very short period of time while the image is updated.

You should be using a Timer to perform a UI task at some point in the future. Just set it to run once, and with a 1 second interval. Put the UI code in the tick event and then set it off.

If you really wanted to use tasks, you'd want to have the other task not run in the UI thread but rather in a background threat (i.e. just a regular StartNew task) and then use the Control.Invoke inside of the task to run a command on the UI thread. The problem here is that is' band-aid-ing the underlying problem of starting a task just to have it sleep. Better to just have the code not even execute in the first place for the full second.