HostingEnvironment.QueueBackgroundWorkItem使用ASP.Net线程池还是其他线程池?

时间:2015-07-11 16:47:37

标签: asp.net background-task

我有一个ASP.Net应用程序,其中后台任务使用 HostingEnvironment.QueueBackgroundWorkItem 运行,如下面的代码所示。

问题:后台任务是否在下面的代码中安排,使用ASP.Net线程池线程中的线程,还是使用来自单独线程池的线程?

public ActionResult SendCustMails()
{
      HostingEnvironment.QueueBackgroundWorkItem(ct => SendCustMailsTo(ct, "Customer Notification"));
      return View();
}

private void SendCustMailsTo (CancellationToken ct, string msg)
{
      //some code is omitted
      foreach (var customer in Customers)
      {
            if (ct.IsCancellationRequested)
            {
                  break;
            }

            SendMail(customer, msg);
      }

      return ct;
}

1 个答案:

答案 0 :(得分:2)

Hosting environment source code可以看出,QueueBackgroundWorkItem方法使用_backGroundWorkScheduler字段作为BackgroundWorkScheduler的类型来安排后台工作项:

public sealed class HostingEnvironment : MarshalByRefObject {
//other field declarations
private static HostingEnvironment _theHostingEnvironment;
private BackgroundWorkScheduler _backgroundWorkScheduler = null; // created on demand
//yet more field declarations


//methods
 [SecurityPermission(SecurityAction.LinkDemand, Unrestricted = true)]
    public static void QueueBackgroundWorkItem(Action<CancellationToken> workItem) {
        if (workItem == null) {
            throw new ArgumentNullException("workItem");
        }

        QueueBackgroundWorkItem(ct => { workItem(ct); return _completedTask; });
    }

    // See documentation on the other overload for a general API overview.
    //
    // This overload of QueueBackgroundWorkItem takes a Task-returning callback; the
    // work item will be considered finished when the returned Task transitions to a
    // terminal state.
    [SecurityPermission(SecurityAction.LinkDemand, Unrestricted = true)]
    public static void QueueBackgroundWorkItem(Func<CancellationToken, Task> workItem) {
        if (workItem == null) {
            throw new ArgumentNullException("workItem");
        }
        if (_theHostingEnvironment == null) {
            throw new InvalidOperationException(); // can only be called within an ASP.NET AppDomain
        }

        _theHostingEnvironment.QueueBackgroundWorkItemInternal(workItem);
    }

    private void QueueBackgroundWorkItemInternal(Func<CancellationToken, Task> workItem) {
        Debug.Assert(workItem != null);

        BackgroundWorkScheduler scheduler = Volatile.Read(ref _backgroundWorkScheduler);

        // If the scheduler doesn't exist, lazily create it, but only allow one instance to ever be published to the backing field
        if (scheduler == null) {
            BackgroundWorkScheduler newlyCreatedScheduler = new BackgroundWorkScheduler(UnregisterObject, Misc.WriteUnhandledExceptionToEventLog);
            scheduler = Interlocked.CompareExchange(ref _backgroundWorkScheduler, newlyCreatedScheduler, null) ?? newlyCreatedScheduler;
            if (scheduler == newlyCreatedScheduler) {
                RegisterObject(scheduler); // Only call RegisterObject if we just created the "winning" one
            }
        }

        scheduler.ScheduleWorkItem(workItem);
    }
//yet more methods

}

如果我们查看BackgroundWorkScheduler课程的源代码:

internal sealed class BackgroundWorkScheduler : IRegisteredObject {
//....
public void ScheduleWorkItem(Func<CancellationToken, Task> workItem) {
        Debug.Assert(workItem != null);

        if (_cancellationTokenHelper.IsCancellationRequested) {
            return; // we're not going to run this work item
        }

        // Unsafe* since we want to get rid of Principal and other constructs specific to the current ExecutionContext
        ThreadPool.UnsafeQueueUserWorkItem(state => {
            lock (this) {
                if (_cancellationTokenHelper.IsCancellationRequested) {
                    return; // we're not going to run this work item
                }
                else {
                    _numExecutingWorkItems++;
                }
            }

            RunWorkItemImpl((Func<CancellationToken, Task>)state);
        }, workItem);
    }
//other methods
}

我们可以注意到它在内部使用Asp.Net ThreadPool来安排工作项。