Завдання. Запустити з параметрами?

Я працюю над багатозадачним мережевим проектом, і я новачок у цьому Threading.Tasks. Я реалізував просте, Task.Factory.StartNew()і мені цікаво, як я можу це зробити Task.Run()?

Ось основний код:

Task.Factory.StartNew(new Action<object>(
(x) =>
{
    // Do something with 'x'
}), rawData);

Я заглянув System.Threading.Tasks.Taskу браузер об’єктів і не зміг знайти Action<T>подібний параметр. Існує тільки Actionщо приймає voidпараметр і не типу .

Існує лише дві подібні речі: static Task Run(Action action)і, static Task Run(Func<Task> function)але не можна розміщувати параметри з обома.

Так, я знаю , що можу створити простий метод розширення для нього , але мій головне питання ми можемо написати його на одній лінії з Task.Run()?

private void RunAsync()
{
    string param = "Hi";
    Task.Run(() => MethodWithParameter(param));
}

private void MethodWithParameter(string param)
{
    //Do stuff
}

Редагувати

Через популярний попит я повинен зазначити, що Taskзапущений буде працювати паралельно із потоком виклику. Якщо припустити, що за замовчуванням TaskSchedulerце буде використовувати .NET ThreadPool. У будь-якому випадку, це означає, що вам потрібно враховувати, які параметри (параметри) передаються до них Taskяк потенційно доступні декільком потокам одночасно, роблячи їх спільним станом. Це включає доступ до них у потоці виклику.

У моєму вище коді цей випадок зроблений повністю спірним. Струни незмінні. Тому я взяв їх як приклад. Але скажімо, ви не використовуєте String...

Одним із рішень є використання asyncта await. Це за замовчуванням захопить SynchronizationContextвиклик потоку і створить продовження для решти методу після виклику awaitта приєднає його до створеного Task. Якщо цей метод запущений у графічному інтерфейсі WinForms, він буде типу WindowsFormsSynchronizationContext.

Продовження триватиме після опублікування назад до захопленого SynchronizationContext- знову лише за замовчуванням. Тож ви повернетесь до теми, з якої почали після awaitдзвінка. Ви можете змінити це різними способами, зокрема, використовуючи ConfigureAwait. Коротше кажучи, інша частина цього методу не буде тривати до тих пір , післяTask завершення іншого потоку. Але викличний потік буде продовжувати працювати паралельно, тільки не решта методу.

Це очікування завершення запуску решти методу може бути або не бути бажаним. Якщо пізніше в цьому методі нічого не доступно до параметрів, переданих Taskвам, ви можете взагалі не захотіти використовувати await.

Або, можливо, ви використовуєте ці параметри значно пізніше в методі. Немає причин awaitнегайно, оскільки ви могли б продовжувати безпечно виконувати роботу. Пам'ятайте, ви можете зберігати Taskповернене у змінній, а awaitпотім - навіть у тому ж методі. Наприклад, як тільки вам потрібно буде безпечно отримати доступ до переданих параметрів, після виконання декількох інших робіт. Знову ж , вам НЕ потрібно awaitна Taskправі , коли ви запустите його.

У будь-якому випадку, простий спосіб зробити цей потік безпечним щодо переданих параметрів Task.Run- це зробити це:

Ви повинні спочатку прикрасити RunAsyncз async:

private async void RunAsync()

Важлива примітка

Переважно, щоб метод, позначений, не повертав недійсним, як згадується у пов'язаній документації. Загальним винятком з цього є обробники подій, такі як клацання кнопок тощо. Вони повинні повернутися недійсними. В іншому випадку я завжди намагаюся повернути a або при використанні . Це хороша практика з багатьох причин.async TaskTask<TResult>async

Тепер ви можете awaitзапустити, Taskяк показано нижче. Ви не можете використовувати awaitбез 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

Отже, загалом, якщо ви ставите awaitзавдання, ви можете уникнути розгляду переданих параметрів як потенційно спільного ресурсу з усіма підводними камінами модифікації чогось із декількох потоків одночасно. Крім того, остерігайтеся закриття . Я не буду їх детально висвітлювати, але пов'язана стаття це чудово справляє.

Бічна примітка

Трохи не в темі, але будьте обережні, використовуючи будь-який тип "блокування" в графічному інтерфейсі WinForms через те, що він позначений [STAThread]. Використання awaitвзагалі не блокує, але іноді я бачу, що воно використовується разом із якимсь блокуванням.

"Блок" в лапках, оскільки технічно ви не можете заблокувати графічний інтерфейс WinForms . Так, якщо ви використовуєте lockграфічний інтерфейс WinForms, він все одно буде перекачувати повідомлення, незважаючи на те, що ви думаєте, що він "заблокований". Це не.

Це може викликати дивні проблеми у дуже рідкісних випадках. lockНаприклад, одна з причин того, що ви ніколи не хочете використовувати, коли малюєте. Але це надзвичайно складний випадок; однак я бачив, що це спричиняє божевільні проблеми. Тож я це зазначив заради повноти.

Використовуйте змінну для захоплення для передачі параметрів.

var x = rawData;
Task.Run(() =>
{
    // Do something with 'x'
});

Ви також можете використовувати rawDataбезпосередньо, але ви повинні бути обережними, якщо ви зміните значення за rawDataмежами завдання (наприклад, ітератор у forциклі), це також змінить значення всередині завдання.

Відтепер ви також можете:

Action<int> action = (o) => Thread.Sleep(o);
int param = 10;
await new TaskFactory().StartNew(action, param)

Я знаю, що це стара тема, але я хотів поділитися рішенням, яке мені довелося використати, оскільки прийнятий пост все ще має проблему.

Питання:

Як зазначив Олександр Северіно, якщо param(у функції нижче) зміниться незабаром після виклику функції, ви можете отримати несподівану поведінку в MethodWithParameter.

Task.Run(() => MethodWithParameter(param)); 

Моє рішення:

Щоб пояснити це, я в підсумку написав щось на зразок наступного рядка коду:

(new Func<T, Task>(async (p) => await Task.Run(() => MethodWithParam(p)))).Invoke(param);

Це дозволило мені безпечно використовувати параметр асинхронно, незважаючи на те, що параметр дуже швидко змінився після запуску завдання (що спричинило проблеми з розміщеним рішенням).

Використовуючи цей підхід, param(тип значення) передає своє значення, тому, навіть якщо метод асинхронізації запускається після paramзмін, pбуде мати те значення, яке paramбуло на момент запуску цього рядка коду.

Просто використовуйте Task.Run

var task = Task.Run(() =>
{
    //this will already share scope with rawData, no need to use a placeholder
});

Або, якщо ви хочете використовувати його в методі і чекати завдання пізніше

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;
}

Незрозуміло, чи була вихідна проблема такою ж, як і у мене: бажання максимізувати потоки процесора при обчисленні всередині циклу, зберігаючи значення ітератора та зберігаючи вбудованість, щоб уникнути передачі тонни змінних робочій функції.

for (int i = 0; i < 300; i++)
{
    Task.Run(() => {
        var x = ComputeStuff(datavector, i); // value of i was incorrect
        var y = ComputeMoreStuff(x);
        // ...
    });
}

Я змусив це працювати, змінивши зовнішній ітератор і локалізувавши його значення за допомогою шлюзу.

for (int ii = 0; ii < 300; ii++)
{
    System.Threading.CountdownEvent handoff = new System.Threading.CountdownEvent(1);
    Task.Run(() => {
        int i = ii;
        handoff.Signal();

        var x = ComputeStuff(datavector, i);
        var y = ComputeMoreStuff(x);
        // ...

    });
    handoff.Wait();
}

Ідея полягає в тому, щоб уникати використання сигналу, як вище. Перекачування значень int у структуру заважає цим значенням змінюватися (у структурі). У мене була така проблема: цикл var я змінювався до виклику DoSomething (i) (я збільшувався в кінці циклу до () => DoSomething (i, i i)). Зі структурами це вже не відбувається. Неприємна помилка для пошуку: DoSomething (i, i i) виглядає чудово, але ніколи не впевнений, що його кожного разу викликають з іншим значенням i (або просто 100 разів із i = 100), отже -> struct

struct Job { public int P1; public int P2; }
…
for (int i = 0; i < 100; i++) {
    var job = new Job { P1 = i, P2 = i * i}; // structs immutable...
    Task.Run(() => DoSomething(job));
}