Cách đơn giản nhất để thực hiện phương pháp chữa cháy và quên trong c # 4.0

Tôi thực sự thích câu hỏi này:

Cách đơn giản nhất để thực hiện phương pháp chữa cháy và quên trong C #?

Tôi chỉ muốn biết rằng bây giờ chúng ta có các tiện ích mở rộng Song song trong C # 4.0, có cách nào tốt hơn để thực hiện Fire & Forget với Parallel linq không?

Không phải là câu trả lời cho 4.0, nhưng đáng chú ý là trong .Net 4.5, bạn có thể làm cho việc này đơn giản hơn với:

#pragma warning disable 4014
Task.Run(() =>
{
    MyFireAndForgetMethod();
}).ConfigureAwait(false);
#pragma warning restore 4014

Pragma là vô hiệu hóa cảnh báo cho biết bạn đang chạy Tác vụ này như lửa và quên.

Nếu phương thức bên trong dấu ngoặc nhọn trả về một Tác vụ:

#pragma warning disable 4014
Task.Run(async () =>
{
    await MyFireAndForgetMethod();
}).ConfigureAwait(false);
#pragma warning restore 4014

Hãy chia nhỏ điều đó:

Task.Run trả về một Tác vụ tạo ra cảnh báo trình biên dịch (cảnh báo CS4014) lưu ý rằng mã này sẽ được chạy trong nền - đó chính xác là những gì bạn muốn, vì vậy chúng tôi vô hiệu hóa cảnh báo 4014.

Theo mặc định, Task cố gắng "Marshal trở lại Thread ban đầu", có nghĩa là Task này sẽ chạy ở chế độ nền, sau đó cố gắng quay trở lại Thread đã bắt đầu nó. Thường kích hoạt và quên Nhiệm vụ hoàn thành sau khi Chủ đề ban đầu hoàn thành. Điều đó sẽ khiến một ThreadAbortException được ném ra. Trong hầu hết các trường hợp, điều này là vô hại - nó chỉ nói với bạn rằng, tôi đã cố gắng tham gia lại, tôi đã thất bại, nhưng dù sao thì bạn cũng không quan tâm. Nhưng vẫn hơi ồn ào khi có ThreadAbortExceptions trong nhật ký của bạn trong Sản xuất hoặc trong trình gỡ lỗi của bạn trong nhà phát triển cục bộ. .ConfigureAwait(false)chỉ là một cách để giữ cho gọn gàng và nói rõ ràng là chạy cái này ở chế độ nền, và thế là xong.

Vì điều này là dài dòng, đặc biệt là pragma xấu xí, tôi sử dụng phương pháp thư viện cho điều này:

public static class TaskHelper
{
    /// <summary>
    /// Runs a TPL Task fire-and-forget style, the right way - in the
    /// background, separate from the current thread, with no risk
    /// of it trying to rejoin the current thread.
    /// </summary>
    public static void RunBg(Func<Task> fn)
    {
        Task.Run(fn).ConfigureAwait(false);
    }

    /// <summary>
    /// Runs a task fire-and-forget style and notifies the TPL that this
    /// will not need a Thread to resume on for a long time, or that there
    /// are multiple gaps in thread use that may be long.
    /// Use for example when talking to a slow webservice.
    /// </summary>
    public static void RunBgLong(Func<Task> fn)
    {
        Task.Factory.StartNew(fn, TaskCreationOptions.LongRunning)
            .ConfigureAwait(false);
    }
}

Sử dụng:

TaskHelper.RunBg(async () =>
{
    await doSomethingAsync();
}

Với Tasklớp là có, nhưng PLINQ thực sự là để truy vấn qua các bộ sưu tập.

Một cái gì đó như sau sẽ làm điều đó với Task.

Task.Factory.StartNew(() => FireAway());

Hoặc thậm chí ...

Task.Factory.StartNew(FireAway);

Hoặc là...

new Task(FireAway).Start();

Trong trường hợp FireAwaylà

public static void FireAway()
{
    // Blah...
}

Vì vậy, nhờ độ ngắn gọn của lớp và phương thức, điều này đánh bại phiên bản threadpool từ sáu đến mười chín ký tự tùy thuộc vào ký tự bạn chọn :)

ThreadPool.QueueUserWorkItem(o => FireAway());

Tôi có một vài vấn đề với câu trả lời hàng đầu cho câu hỏi này.

Đầu tiên, trong một tình huống cháy nổ thực sự , bạn có thể sẽ không thực awaithiện nhiệm vụ, vì vậy việc phụ thêm cũng vô ích ConfigureAwait(false). Nếu bạn không awaittrả về giá trị ConfigureAwait, thì nó không thể có bất kỳ tác dụng nào.

Thứ hai, bạn cần biết điều gì sẽ xảy ra khi nhiệm vụ hoàn thành với một ngoại lệ. Hãy xem xét giải pháp đơn giản mà @ ade-miller đã đề xuất:

Task.Factory.StartNew(SomeMethod);  // .NET 4.0
Task.Run(SomeMethod);               // .NET 4.5

Điều này dẫn đến một mối nguy hiểm: nếu một ngoại lệ chưa được xử lý thoát khỏi SomeMethod(), ngoại lệ đó sẽ không bao giờ được quan sát và ¹ có thể được phát triển lại trên chuỗi trình hoàn thiện, làm hỏng ứng dụng của bạn. Do đó, tôi khuyên bạn nên sử dụng phương pháp trợ giúp để đảm bảo rằng mọi ngoại lệ kết quả đều được tuân thủ.

Bạn có thể viết một cái gì đó như thế này:

public static class Blindly
{
    private static readonly Action<Task> DefaultErrorContinuation =
        t =>
        {
            try { t.Wait(); }
            catch {}
        };

    public static void Run(Action action, Action<Exception> handler = null)
    {
        if (action == null)
            throw new ArgumentNullException(nameof(action));

        var task = Task.Run(action);  // Adapt as necessary for .NET 4.0.

        if (handler == null)
        {
            task.ContinueWith(
                DefaultErrorContinuation,
                TaskContinuationOptions.ExecuteSynchronously |
                TaskContinuationOptions.OnlyOnFaulted);
        }
        else
        {
            task.ContinueWith(
                t => handler(t.Exception.GetBaseException()),
                TaskContinuationOptions.ExecuteSynchronously |
                TaskContinuationOptions.OnlyOnFaulted);
        }
    }
}

Việc triển khai này phải có chi phí tối thiểu: phần tiếp tục chỉ được gọi nếu tác vụ không hoàn thành thành công và nó phải được gọi đồng bộ (trái ngược với việc được lên lịch riêng với tác vụ ban đầu). Trong trường hợp "lười biếng", bạn thậm chí sẽ không bị phân bổ cho đại biểu tiếp tục.

Bắt đầu một hoạt động không đồng bộ sau đó trở nên tầm thường:

Blindly.Run(SomeMethod);                              // Ignore error
Blindly.Run(SomeMethod, e => Log.Warn("Whoops", e));  // Log error

_{1. Đây là hành vi mặc định trong .NET 4.0. Trong .NET 4.5, hành vi mặc định đã được thay đổi để các ngoại lệ không được quan sát sẽ không được phát triển lại trên chuỗi trình hoàn thiện (mặc dù bạn vẫn có thể quan sát chúng qua sự kiện UnobservedTaskException trên TaskScheduler). Tuy nhiên, cấu hình mặc định có thể bị ghi đè và ngay cả khi ứng dụng của bạn yêu cầu .NET 4.5, bạn không nên cho rằng các ngoại lệ tác vụ không được quan sát sẽ vô hại.}

Chỉ để khắc phục một số vấn đề sẽ xảy ra với câu trả lời của Mike Strobel:

Nếu bạn sử dụng var task = Task.Run(action)và sau khi chỉ định một phần tiếp theo cho tác vụ đó, thì bạn sẽ có nguy cơ Taskném một số ngoại lệ trước khi bạn chỉ định một phần tiếp theo của trình xử lý ngoại lệ cho Task. Vì vậy, lớp dưới đây sẽ không có rủi ro này:

using System;
using System.Threading.Tasks;

namespace MyNameSpace
{
    public sealed class AsyncManager : IAsyncManager
    {
        private Action<Task> DefaultExeptionHandler = t =>
        {
            try { t.Wait(); }
            catch { /* Swallow the exception */ }
        };

        public Task Run(Action action, Action<Exception> exceptionHandler = null)
        {
            if (action == null) { throw new ArgumentNullException(nameof(action)); }

            var task = new Task(action);

            Action<Task> handler = exceptionHandler != null ?
                new Action<Task>(t => exceptionHandler(t.Exception.GetBaseException())) :
                DefaultExeptionHandler;

            var continuation = task.ContinueWith(handler,
                TaskContinuationOptions.ExecuteSynchronously
                | TaskContinuationOptions.OnlyOnFaulted);
            task.Start();

            return continuation;
        }
    }
}

Ở đây, lệnh taskkhông được chạy trực tiếp, thay vào đó nó được tạo, một phần tiếp theo được chỉ định và chỉ sau đó tác vụ được chạy để loại bỏ nguy cơ tác vụ hoàn thành việc thực thi (hoặc ném một số ngoại lệ) trước khi chỉ định một phần tiếp theo.

Các Runphương pháp ở đây trả về việc tiếp tục Tasknhư vậy tôi có thể viết bài kiểm tra đơn vị đảm bảo việc thực hiện hoàn tất. Tuy nhiên, bạn có thể bỏ qua nó một cách an toàn trong cách sử dụng của mình.