Task.Run with Parameter(s)?
Solution 1
private void RunAsync()
{
//Beware of closures. String is immutable.
string param = "Hi";
Task.Run(() => MethodWithParameter(param));
}
private void MethodWithParameter(string param)
{
//Do stuff
}
Edit
Due to popular demand I must note that the Task
launched will run in parallel with the calling thread. Assuming the default TaskScheduler
this will use the .NET ThreadPool
. Anyways, this means you need to account for whatever parameter(s) being passed to the Task
as potentially being accessed by multiple threads at once, making them shared state. This includes accessing them on the calling thread.
In my above code that case is made entirely moot. Strings are immutable. That's why I used them as an example. But say you're not using a String
...
One solution is to use async
and await
. This, by default, will capture the SynchronizationContext
of the calling thread and will create a continuation for the rest of the method after the call to await
and attach it to the created Task
. If this method is running on the WinForms GUI thread it will be of type WindowsFormsSynchronizationContext
.
The continuation will run after being posted back to the captured SynchronizationContext
- again only by default. So you'll be back on the thread you started with after the await
call. You can change this in a variety of ways, notably using ConfigureAwait
. In short, the rest of that method will not continue until after the Task
has completed on another thread. But the calling thread will continue to run in parallel, just not the rest of the method.
This waiting to complete running the rest of the method may or may not be desirable. If nothing in that method later accesses the parameters passed to the Task
you may not want to use await
at all.
Or maybe you use those parameters much later on in the method. No reason to await
immediately as you could continue safely doing work. Remember, you can store the Task
returned in a variable and await
on it later - even in the same method. For instance, once you need to access the passed parameters safely after doing a bunch some other work. Again, you do not need to await
on the Task
right when you run it.
Anyways, a simple way to make this thread-safe with respect to the parameters passed to Task.Run
is to do this:
You must first decorate RunAsync
with async
:
private async void RunAsync()
Important Notes
Preferably the method marked async
should not return void, as the linked documentation mentions. The common exception to this is event handlers such as button clicks and such. They must return void. Otherwise I always try to return a Task
or Task<TResult>
when using async
. It's good practice for a quite a few reasons.
Now you can await
running the Task
like below. You cannot use await
without async
.
await Task.Run(() => MethodWithParameter(param));
//Code here and below in the same method will not run until AFTER the above task has completed in one fashion or another
So, in general, if you await
the task you can avoid treating passed in parameters as a potentially shared resource with all the pitfalls of modifying something from multiple threads at once. Also, beware of closures. I won't cover those in depth but the linked article does a great job of it.
Regarding Run
and StartNew
the code below I find most important to know, really. There are legitimate reasons to use either, neither is obsolete or "better" than the other. Be aware simply replacing one with the other is a very bad idea unless you understand this:
//These are exactly the same
Task.Run(x);
Task.Factory.StartNew(x, CancellationToken.None,
TaskCreationOptions.DenyChildAttach, TaskScheduler.Default);
//These are also exactly the same
Task.Factory.StartNew(x);
Task.Factory.StartNew(x, CancellationToken.None,
TaskCreationOptions.None, TaskScheduler.Current);
Side Notes
A bit off topic, but be careful using any type of "blocking" on the WinForms GUI thread due to it being marked with [STAThread]
. Using await
won't block at all, but I do sometimes see it used in conjunction with some sort of blocking.
"Block" is in quotes because you technically cannot block the WinForms GUI thread. Yes, if you use lock
on the WinForms GUI thread it will still pump messages, despite you thinking it's "blocked". It's not.
This can cause bizarre issues in very rare cases. One of the reasons you never want to use a lock
when painting, for example. But that's a fringe and complex case; however I've seen it cause crazy issues. So I noted it for completeness sake.
Solution 2
Use variable capture to "pass in" parameters.
var x = rawData;
Task.Run(() =>
{
// Do something with 'x'
});
You also could use rawData
directly but you must be careful, if you change the value of rawData
outside of a task (for example a iterator in a for
loop) it will also change the value inside of the task.
Solution 3
From now you can also :
Action<int> action = (o) => Thread.Sleep(o);
int param = 10;
await new TaskFactory().StartNew(action, param)
Solution 4
I know this is an old thread, but I wanted to share a solution I ended up having to use since the accepted post still has an issue.
The Issue:
As pointed out by Alexandre Severino, if param
(in the function below) changes shortly after the function call, you might get some unexpected behavior in MethodWithParameter
.
Task.Run(() => MethodWithParameter(param));
My Solution:
To account for this, I ended up writing something more like the following line of code:
(new Func<T, Task>(async (p) => await Task.Run(() => MethodWithParam(p)))).Invoke(param);
This allowed me to safely use the parameter asynchronously despite the fact that the parameter changed very quickly after starting the task (which caused issues with the posted solution).
Using this approach, param
(value type) gets its value passed in, so even if the async method runs after param
changes, p
will have whatever value param
had when this line of code ran.
Solution 5
Just use Task.Run
var task = Task.Run(() =>
{
//this will already share scope with rawData, no need to use a placeholder
});
Or, if you would like to use it in a method and await the task later
public Task<T> SomethingAsync<T>()
{
var task = Task.Run(() =>
{
//presumably do something which takes a few ms here
//this will share scope with any passed parameters in the method
return default(T);
});
return task;
}
Thus Spoke Nomad
Updated on December 08, 2021Comments
-
Thus Spoke Nomad over 2 years
I'm working on a multi-tasking network project and I'm new on
Threading.Tasks
. I implemented a simpleTask.Factory.StartNew()
and I wonder how can I do it withTask.Run()
?Here is the basic code:
Task.Factory.StartNew(new Action<object>( (x) => { // Do something with 'x' }), rawData);
I looked into
System.Threading.Tasks.Task
in Object Browser and I couldn't find aAction<T>
like parameter. There is onlyAction
that takesvoid
parameter and no type.There are only 2 things similiar:
static Task Run(Action action)
andstatic Task Run(Func<Task> function)
but can't post parameter(s) with both.Yes, I know I can create a simple extension method for it but my main question is can we write it on single line with
Task.Run()
? -
Scott Chamberlain almost 9 yearsJust be careful of closures if you do it that way
for(int rawData = 0; rawData < 10; ++rawData) { Task.Run(() => { Console.WriteLine(rawData); } ) }
will not behave the same as ifrawData
was passed in like in the OP's StartNew example. -
Travis J almost 9 years@ScottChamberlain - That seems like a different example ;) I would hope most people understand about closing over lambda values.
-
Alexandre Severino almost 9 yearsYou are not awaiting
Task.Run(() => MethodWithParameter(param));
. Which means that ifparam
gets modified after theTask.Run
, you might have unexpected results on theMethodWithParameter
. -
Travis J almost 9 yearsAnd if those previous comments made no sense, please see Eric Lipper's blog on the topic: blogs.msdn.com/b/ericlippert/archive/2009/11/12/… It explains why this happens very well.
-
Alexandre Severino almost 9 years+1 for taking into consideration the important fact that the variable might be changed right after calling
Task.Run
. -
Zer0 almost 9 years@Kilouco Of course. That's the expected behavior when passing by reference. Same would happen if you did
ThreadPool.QueueUserWorkItem(x => { MethodWithParameter((string)x); }, param);
Welcome to threading, don't shoot yourself in the foot... -
Alexandre Severino almost 9 yearsI'm just suggesting giving OP a heads-up about this risk.
-
Thus Spoke Nomad almost 9 yearsI'm accepting answer because of clear/simple implementation. There is no
Task.Run(Action<T>)
like method to call. Thanks! -
ovi almost 8 yearshow is this going to help? if you use x inside the task thread, and x is a reference to an object, and if the object is modified in the same time when the task thread is running it can lead to havoc.
-
Scott Chamberlain almost 8 years@Ovi-WanKenobi Yes, but that is not what this question was about. It was how to pass a parameter. If you passed a reference to a object as a parameter to a normal function you would have the exact same problem there too.
-
Admin over 7 yearsI eagerly await anyone who can think of a way to do this more legibly with less overhead. This is admittedly rather ugly.
-
Stephen Cleary over 7 yearsHere you go:
var localParam = param; await Task.Run(() => MethodWithParam(localParam));
-
Servy over 7 yearsWhich, by the way, Stephen already discussed in his answer, a year and a half ago.
-
Stephen Cleary over 7 years@Servy: That was Scott's answer, actually. I didn't answer this one.
-
Admin over 7 yearsScott's answer would not have worked for me actually, as I was running this in a for loop. The local param would have been reset in the next iteration. The difference in the answer I posted is that the param gets copied into the scope of the lambda expression, so the variable is immediately safe. In Scott's answer, the parameter is still in the same scope, so it could still change between calling the line, and executing the async function.
-
Egor Pavlikhin about 7 yearsWhy is this an accepted answer when it's wrong. It's not at all equivalent of passing state object.
-
Egor Pavlikhin about 7 years@Zer0 a state object is the second paremeter in Task.Factory.StartNew msdn.microsoft.com/en-us/library/dd321456(v=vs.110).aspx and it saves the value of the object at the moment of the call to StartNew, while your answer creates a closure, which keeps the reference (if the value of param changes before the task is run it will also change in the task), so your code is not at all equivalent to what the question was asking. The answer really is that there is no way to write it with Task.Run().
-
Zer0 about 7 years@EgorPavlikhin - What?
Task.Run
is short-hand forTask.Factory.StartNew
. They are quite literally one in the same. I want this crystal clear so no one gets misinformation from your comment. Modifying an object you pass toTask.Factory.StartNew
is not thread-safe. It does not create a copy. It's just as dangerous as using a closure. You're far beyond the scope of OP's question. Yet again, I answered his simple bolded question correctly. This isn't an in depth class on closures. EOD. -
Zer0 about 7 years@EgorPavlikhin - For you, and others, see here for a better discussion of that particular overload. Totally off-topic but it's more in depth. Outside the scope of this question and a better place to look. Closures are something I'm not going into here. But you can get tripped up by them regardless if you're using
StartNew
orTask.Run
as they do the same thing, one is simply short-hand. -
Egor Pavlikhin almost 7 years@Zer0 for structs Task.Run with closure and Task.Factory.StartNew with 2nd parameter (which is not the same as Task.Run per your link) will behave differently, since in the latter case a copy will be made. My mistake was in referring to objects in general in the original comment, what I meant was that they are not fully equivalent.
-
Zer0 almost 7 years@EgorPavlikhin Still incorrect.
Task.Run
IS absolutely implemented the same way. Did you not read the link I included? Perhaps you should read the actual source code? You are discussing closures, period. Common language feature has no ties with the TPL in any way. Again... closures are a big part of C# and not at all something unique toTask.Run
. You can use the synonymous short hand method without closures too... Lastly closures are dangerous for both reference types and structs. So you're off there as well. End of discussion. -
Egor Pavlikhin almost 7 years@Zer0 Perhaps you should read the source code. One passes the state object, the other one doesn't. Which is what I said from the begining. Task.Run is not a short-hand for Task.Factory.StartNew. The state object version is there for legacy reasons, but it is still there and it behaves differently sometimes, so people should be aware of that.
-
Rick O'Shea over 5 yearsOMG. That's the TL'DR-est explanation of a simple question I've seen yet, and that's usually an indication of not getting the concept therefore not being able to articulate it simply. That said, the example is no good, so explaining why it's no good (not thread safe) is less desirable than just providing a working example or maybe deleting the answer.
-
Harry over 5 years@Zer0 if am doing this, it works fine Task.Run(() => Myfunc(Param1, Param2, Param3, Param4)); but i want to pass the token and taskcreationoptions, so if i do as below i get many errors Task.Run(() => Myfunc(Param1, Param2, Param3, Param4),mycancellationtoken,TaskCreationOptions.LongRunning);
-
Zer0 over 5 years@Harry Task.Run does not support specifying your own task creation options. It defaults to DenyChildAttach (not None). Use Task.Factory.StartNew instead.
-
davidcarr about 5 yearsReading Toub's article I will highlight this sentence " You get to use overloads that accept object state, which for performance-sensitive code paths can be used to avoid closures and the corresponding allocations". I think this is what @Zero is implying when considering Task.Run over StartNew usage.
-
David Price about 5 yearsYup this does not work. My task has no reference back to x in the calling thread. I just get null.
-
Dan about 4 yearsWhile this may answer the question, it was flagged for review. Answers with no explanation are often considered low-quality. Please provide some commentary for why this is the correct answer.
-
Neo over 3 yearsThis is the best answer as it allows a state to be passed in, and prevents the possible situation mentioned in Kaden Burgart's answer. For example, if you need to pass a
IDisposable
object into the task delegate to resolve the ReSharper warning "Captured variable is disposed in the outer scope", this does it very nicely. Contrary to popular belief, there's nothing wrong with usingTask.Factory.StartNew
instead ofTask.Run
where you need to pass state. See here. -
RashadRivera over 3 yearsScott Chamberlain, Passing argument via capture comes with its own issues. In particular, there is the issue of memory leaking and memory pressure. In particular when you try to scale up. (see "8 Ways You can Cause Memory Leaks" for more details).
-
Paul B. over 2 yearsIn case anyone else wants to see the difference that @Zer0 pointed out - try
for (int i = 1; i < 20; i++) { Task.Run(() => Console.Out.WriteLine(i)); }
vsfor (int i = 1; i < 20; i++) { Task.Factory.StartNew((j) => Console.Out.WriteLine(j), i); }
-
Kirsan about 2 yearsWhile this is good a point direction what to do, but the example above will not compile.
StartNew
needAction<object>
as parameter...