小编Mad*_*ter的帖子

我有几个ASP.Net MVC和WebAPI项目.其中大多数都是最新的(MVC 5/WebAPI 2).我一直在仔细检查我的安全假设,因为我正在实现一个全局过滤器(用于MVC)和一个委托处理程序(用于WebAPI)来统一整个系统的安全性.

在这种情况下,我遇到了一些文章和帖子(见下文),其中说你应该总是设置UseTaskFriendlySynchronizationContext为true(默认为false).这对我来说似乎很奇怪,因为即使在VS2013中使用MVC 5和WebAPI 2新项目模板(以及ASP.Net WebForms模板)也根本不设置此应用程序设置.

关于此设置的MSDN文档几乎不存在,我发现的帖子确实说它是异步编程所必需的,似乎是在WebForms的上下文中.

所以这是我的问题:

1. 此设置是否适用于ASP.Net的所有内容,还是特定于ASP.Net中的页面生命周期内容(我没有多少使用)
2. 如果它对于现代异步编程至关重要,为什么没有任何教程或模板引用它？
3. 在使用ConfigureAwait(false)的引用库中使用Thread.CurrentPrincipal的声明会造成任何问题,或者ExecutionContext的逻辑调用上下文的流动会在那里照顾我吗？(到目前为止我的阅读和测试表明它会)

以下是我见过的一些文章UseTaskFriendlySynchronizationContext:

• 设置Thread.CurrentPrincipal异步？
• MSDN上的ASP.NET appSettings元素
• "UseTaskFriendlySynchronizationContext"的含义是什么？
• SynchronizationContext由Marcus van Houdt 理解ASP.NET中的内容
• 为什么Thread.CurrentPrincipal需要"await Task.Yield()"才能正确流动？

一些文章真正帮助我掌握了所有这些东西的作用,从未提及UseTaskFriendlySynchronizationContext:

• 由Stephen Toub执行的ExecutionContext与SynchronizationContext
• 它是关于Stephen Cleary的SynchronizationContext的全部内容

在使用ConfigureAwait(false)的引用库中使用Thread.CurrentPrincipal的声明会造成任何问题,或者ExecutionContext的逻辑调用上下文的流动会在那里照顾我吗？(到目前为止,我的阅读和测试表明它会).

示例WebAPI控制器操作:

[CustomAuthorizeThatSetsCurrentUsersClaimsToThreadCurrentContextAndHttpContextCurrentUser]
public async Task<Order> Get(int orderId)
{
    return await _orderBusinessLogicLibrary.LoadAsync(orderId); // defaults to .ConfigureAwait(true)
}

来自外部引用库的示例加载函数:

[ClaimsPrincipalPermission(
    SecurityAction.Demand,
    Operation="Read",
    Resource="Orders")]
[ClaimsPrincipalPermission(
    SecurityAction.Demand,
    Operation="Read",
    Resource="OrderItems")]
public async Task<Order> Load(int orderId)
{
    var order = await _repository.LoadOrderAsync(orderId).ConfigureAwait(false);

    // here's the key line.. assuming this lower-level function is also imposing
    // security constraints in the same way this method does, would
    // Thread.CurrentPrincipal still be correct inside the function below?
    order.Items = await _repository.LoadOrderItemsAsync(orderId).ConfigureAwait(false);
    return order;
}

此外,答案不能是"那么不要使用ConfigureAwait(false)!".这可能会导致其他问题,例如死锁(请勿在异步代码上阻止).

好吧,所以我遇到了一个奇怪的小问题,坦白说我没有想法.我想把它扔出去看看我是否遗漏了一些我做错了,或者ConcurrentDictionary无法正常工作的东西.这是代码:

(Cache是​​一个包含静态ConcurrentDictionary键的类)

var tmp = Cache.Keys.GetOrAdd(type,
                key =>
                {
                    var keys = context.GetKeys(key);
                    if (keys.Count() == 1)
                    {
                        return new KeyInfo
                            {
                                Name = keys.First().Name,
                                Info = key.GetInfo(keys.First().Name)
                            };
                    }

                    return null;
                });

            if (tmp == null)
                Cache.Keys.TryRemove(type, out tmp);

            return tmp;

问题是,偶尔tmp会null导致TryRemove线路运行,但return null;上面的线路永远不会被击中.由于这return null是唯一将null进入词典,它永远不会运行,怎么可能tmp永远是null？

包括Cache类(此代码不使用SetNames):

public class Cache
{
    public static ConcurrentDictionary<Type, Info> Keys = new ConcurrentDictionary<Type, Info>();
    public static ConcurrentDictionary<Type, string> SetNames …