C#异步编程(五)异步的同步构造
2021-07-13 00:07
标签:aac dea span consumer 添加 result 伸缩性 display free 任何使用了内核模式的线程同步构造,我都不是特别喜欢。因为所有这些基元都会阻塞一个线程的运行。创建线程的代价很大。创建了不用,这于情于理说不通。 创建了reader-writer锁的情况,如果写锁被长时间占有,那么其他的读请求线程都会被阻塞,随着越来越多客户端请求到达,服务器创建了更多的线程,而他们被创建出来的目的就是让他们在锁上停止运行。更糟糕的是,一旦writer锁释放,所有读线程都同时解除阻塞并开始执行。现在,又变成大量的线程试图在相对数量很少的cpu上运行。所以,windows开始在线程之间不同的进行上下文切换,而真正的工作时间却很少。 锁很流行,但长时间拥有会带来巨大的伸缩性问题。如果代码能通过异步的同步构造指出他想要一个锁,那么会非常有用。在这种情况下,如果线程得不到锁,可直接返回并执行其他工作,而不必在那里傻傻地阻塞。 SemaphoreSlim通过waitAsync实现了这个思路 public Task 使用await asynclock.WaitAsync()就可以实现刚才说的情境。 但如果是reader-writer呢?.net framework提供了concurrentExclusiveSchedulerPair类。实例代码如下: 遗憾的是,framework没有提供鞠咏reader-writer语义的异步锁。所以我们可以自己构建一个,如下: 上述代码永远不会阻塞线程。原因是内部没有没有很实用任何内核构造。这里确实使用了一个SpinLock,它在内部使用了用户模式构造。但是他的执行时间很短,WaitAsync方法里,只是一些整数计算和比较,这也符合只有执行时间很短的代码段才可以用自旋锁来保护。所以使用一个spinLock来保护对queue的访问,还是比较合适的。 FCL自带4个线程安全的集合类,全部在System.Collections.Concurrent命名空间中定义。它们是ConcurrentStack、concurrentQueue、concurrentDictionary、concurrentBag。 所有这些集合都是“非阻塞”的,换而言之,如果一个线程试图提取一个不存在的元素(数据项),线程会立即返回;线程不会阻塞在那里,等着一个元素的出现。正是由于这个原因,所以如果获取了一个数据项,像tryDequeue,tryPop,tryTake和tryGetValue这样的方法全部返回true;否则返回false。 一个集合“非阻塞”,并不意味着他就不需要锁了。concurrentDictionary类在内部使用了Monitor。但是,对集合中的项进行操作时,锁只被占有极短的时间。concurrentQueue和ConcurrentStack确实不需要锁;他们两个在内部都使用interlocked的方法来操纵集合。一个concurrentBag对象由大量迷你集合对象构成,每个线程一个。线程将一个项添加到bag中时,就用interlocked的方法将这个项添加到调用线程的迷你集合中。一个线程视图从bag中提取一个元素时,bag就检查调用线程的迷你集合,试图从中取出数据项。如果数据项在哪里,就用一个interlocked方法提取这个项。如果不在,就在内部获取一个monitor,以便从 线程的迷你集合提取一个项。这称为一个线程从另一个线程“窃取”一个数据项。 注意,所有并发集合类都提供了getEnumerator方法,他一般用于C#的foreach语句,但也可用于Linq。对于concurrentQueue、ConcurrentStack和concurrentBag类,getEnumerator方法获取集合内容的一个“快照”,并从这个快照中返回元素;实际集合内容可能在使用快照枚举时发生改变。concurrentDictionary的getEnumerator的该方法不获取他内容的快照。因此,在枚举字典期间,字典的内容可能改变。还要注意,count属性返回的是查询时集合中的元素数量,如果其他线程同时正在集合中增删,这个计数可能马上就变得不正确。 ConcurrentStack、concurrentQueue、concurrentBag都实现了IProducerConsumerCollection接口,实现了这个接口的任何类都能转变成一个阻塞集合,不过,尽量不使用这种阻塞集合。 这里我们重点介绍下concurrentDictionary。 这里我对.net core中ConcurrentDictionary源码进行了分析,里面采用了Volatile.Read和write,然后也使用了lock这种混合锁,而且还定义了更细颗粒度的锁。所以多线程使用ConcurrentDictionary集合还是比较好的选择。 TryRemove 这个方法会调用内部私用的TryRemoveInternal TryAdd 这个方法会调用内部私用的TryAddInternal TryAddInternal(key, _comparer.GetHashCode(key), value, false, true, out dummy); TryGetValue TryGetValueInternal(key, _comparer.GetHashCode(key), out value); C#异步编程(五)异步的同步构造 标签:aac dea span consumer 添加 result 伸缩性 display free 原文地址:https://www.cnblogs.com/qixinbo/p/9591333.html异步的同步构造
private static void ConcurrentExclusiveSchedulerDemo()
{
var cesp = new ConcurrentExclusiveSchedulerPair();
var tfExclusive = new TaskFactory(cesp.ExclusiveScheduler);
var tfConcurrent = new TaskFactory(cesp.ConcurrentScheduler);
for (int i = 0; i 5; i++)
{
var exclusive = i 2;
(exclusive ? tfExclusive : tfConcurrent).StartNew(() =>
{
Console.WriteLine("{0} access",exclusive?"exclusive":"concurrent");
//这里进行独占写入或者并发读取操作
});
}
}
public sealed class AsyncOneManyLock
{
#region 锁的代码
//自旋锁不要用readonly
private SpinLock m_lock = new SpinLock(true);
private void Lock()
{
bool taken = false;m_lock.Enter(ref taken);
}
private void Unlock()
{
m_lock.Exit();
}
#endregion
#region 锁的状态和辅助方法
private Int32 m_state = 0;
private bool IsFree { get { return m_state == 0; } }
private bool IsOwnedByWriter { get { return m_state == -1; } }
private bool IsOwnedByReader { get { return m_state > 0; } }
private Int32 AddReaders(Int32 count) { return m_state += count; }
private Int32 SubtractReader() { return --m_state; }
private void MakeWriter() { m_state = -1; }
private void MakeFree() { m_state = 0; }
#endregion
//目的实在非竞态条件时增强性能和减少内存消耗
private readonly Task m_noContentionAccessGranter;
//每个等待的writer都通过他们在这里排队的TaskCompletionSource来唤醒
private readonly Queue
并发集合类
ConcurrentDictionary
private bool TryRemoveInternal(TKey key, out TValue value, bool matchValue, TValue oldValue)
{
int hashcode = _comparer.GetHashCode(key);
while (true)
{
Tables tables = _tables;
int bucketNo, lockNo;
//这里获取桶的索引和锁的索引,注意,锁的索引和桶未必是同一个值,具体算法看源码。
GetBucketAndLockNo(hashcode, out bucketNo, out lockNo, tables._buckets.Length, tables._locks.Length);
//这里锁住的只是对应这个index指向的锁,而不是所有锁。
lock (tables._locks[lockNo])
{
//这里table可能被重新分配,所以这里再次获取,看得到的是不是同一个table
// If the table just got resized, we may not be holding the right lock, and must retry.
// This should be a rare occurrence.
if (tables != _tables)
{
continue;
}
Node prev = null;
//这里同一个桶,可能因为连地址,有很多值,所以要对比key
for (Node curr = tables._buckets[bucketNo]; curr != null; curr = curr._next)
{
Debug.Assert((prev == null && curr == tables._buckets[bucketNo]) || prev._next == curr);
//对比是不是要删除的的那个元素
if (hashcode == curr._hashcode && _comparer.Equals(curr._key, key))
{
if (matchValue)
{
bool valuesMatch = EqualityComparer
///
private bool TryGetValueInternal(TKey key, int hashcode, out TValue value)
{
Debug.Assert(_comparer.GetHashCode(key) == hashcode);
//用本地变量保存这个table的快照。
// We must capture the _buckets field in a local variable. It is set to a new table on each table resize.
Tables tables = _tables;
int bucketNo = GetBucket(hashcode, tables._buckets.Length);
// We can get away w/out a lock here.
// The Volatile.Read ensures that we have a copy of the reference to tables._buckets[bucketNo].
// This protects us from reading fields (‘_hashcode‘, ‘_key‘, ‘_value‘ and ‘_next‘) of different instances.
Node n = Volatile.Read