(译)构建Async同步基元,Part 7 AsyncReaderWriterLock
2013-01-18 09:54
573 查看
传送门:异步编程系列目录……
最近在学习.NET4.5关于“并行任务”的使用。“并行任务”有自己的同步机制,没有显示给出类似如旧版本的:事件等待句柄、信号量、lock、ReaderWriterLock……等同步基元对象,但我们可以沿溪这一编程习惯,那么这系列翻译就是给“并行任务”封装同步基元对象。翻译资源来源《(译)关于Async与Await的FAQ》
1. 构建Async同步基元,Part 1 AsyncManualResetEvent
2. 构建Async同步基元,Part 2 AsyncAutoResetEvent
3. 构建Async同步基元,Part 3 AsyncCountdownEvent
4. 构建Async同步基元,Part 4 AsyncBarrier
5. 构建Async同步基元,Part 5 AsyncSemaphore
6. 构建Async同步基元,Part 6 AsyncLock
7. 构建Async同步基元,Part 7 AsyncReaderWriterLock
源码:构建Async同步基元.rar
开始:构建Async同步基元,Part 7 AsyncReaderWriterLock
在上一篇文章中,我们构建了一个AsyncLock,本文,我将构建一个更高级的构造,一个异步版本的读写/锁。
异步版本的读写/锁比前几篇文章中所创建的同步基元要更加复杂。它包含更多的控制,这意味着需要更多决定来构建这个类型的精确行为。对于本例,我做了以下决定。首先,写操作比读操作拥有更高的优先级,即无论读操作或写操作请求的顺序,如果有写操作正在等待,它将得到优先于任何数量的读操作得到处理,即使它比那些读操作请求的晚些。第二,我决定不对读操作限流,即只要此时不存在未解决的写操作或等待着的写操作,所有读操作会立马被唤醒。
这是我们将构建的目标类型:
就像AsyncLock一样,我们使用一个实现IDiposable接口的Releaser结构,使AsyncReaderWriterLock类型能轻易用于一个范围,例如:
现在构建Releaser结构,我们使用一个bool值类型变量标识是否是写操作,因为我们需要使用不同的方式来唤醒两种操作的锁(优先处理写操作)。
因为AsyncReaderWriterLock比前几篇文章中所创建的同步基元要更加复杂,所以我需要更多成员变量。首先,我们为了提高性能,我为读操作的等待缓存了一个Task<Releaser>,同时也为写操作的等待缓存了一个Task<Releaser>以便立即完成。
接下来,我需要为写操作维护一个等待队列,对于每一个写操作等待者都有对应的Task<CompletionSource>实例,因为我需要支持单独唤醒它们。同样也需要为读操作维护一个TaskCompletionSource<Releaser>实例。然而,对于读操作,按我们之前谈论的设计,当允许读操作运行时,就能让所有读操作一起运行,因此我只需要一个TaskCompletionSource<Releaser>实例。然而,因为我为读操作只维护了一个TaskCompletionSource<Releaser>实例,所以我还需要知道有多少个读操作正在等待,以便当我最终唤醒它们时,我能确保所有读操作被唤醒。
最后,我需要一个变量来维护锁的当前状态,它是一个整型,数值为0表示锁空闲;数值为-1表示一个写操作获取锁;正值表示一个或多个读操作获取锁。
现在我们来实现4个方法:ReaderLockAsync, ReaderRelease, WriterLockAsync, and WriterRelease。(为了保证这4个方法数据的同步,我们首先对m_waitingWriters加锁)
ReaderLockAsync()方法用于读操作获取锁。在对m_waitingWriters加独占锁后,我们需要决定读操作是应该立即响应还是应该被迫等待。正如前面的决策,如果当前不存在等待的写操作或正在执行写操作,则读操作能立即得到响应,这种情况下,我们递增m_status计数并且返回为读操作缓存的TaskCompletionSource<Releaser>实例。如果当前存在等待的写操作或正在执行写操作,则我们强迫读操作等待,我们递增m_readersWaiting计数并且为读操作缓存的TaskCompletionSource<Releaser>实例添加延续任务并返回(延续任务确保所有的等待者能并发运行而不是串行化)。
WriterLockAsync()用于写操作获取锁。就像ReaderLockAsync()方法一样,需要对m_waitingWriters加独占锁,并且要考虑两种情况:写操作要么立即被响应,要么被迫等待。只有当前锁是空闲状态写操作才能立即被响应,因为写操作不能和任意读操作或其他写操作同时运行。所以,如果m_status值为0,我们更改m_status为-1表示现在正在运行一个写操作,并且返回为写操作缓存的Queue<TaskCompletionSource<Releaser>>队列。否则,我们为写操作创建一个新的TaskCompletionSource<Releaser>实例插入到队列中并且返回此实例对应的Task。
现在我们来构建唤醒功能,这些功能在被激活的读操作或写操作完成工作并且想释放它们持有的锁时被调用。ReaderRelease()需要递减读操作激活数计数,并且检查当前锁的状态。如果此时唤醒的是最后一个激活的读操作并且存在写操作正在等待,则会唤醒一个写操作并且设置m_status值为-1标识写操作获得锁。我们不需要检查任何等待的读操作,因为写操作比任何数量的读操作优先得到处理。如果此时没有任何等待的写操作,则任一后续请求的读操作将立即被响应。
最后,我们构建WriterRelease()方法。当读操作完成时,如果等待队列中存在等待的写操作,我们从队列中取出一个写操作并且完成任务(因为将激活一个新的写操作,旧的写操作完成后,新的写操作会取代它的位置,所以不需要更新锁的状态m_status)。如果等待队列中不存在等待的写操作,但是此时存在等待的读操作,我们会唤醒所有读操作对应的任务,在这种情况下,我们还要为后续的读操作创建一个新的等待任务,并且需要更新m_status为当前激活的读操作数。如果没有任何读操作或写操作,则我们重置锁状态m_status。
这就是本节要讲的AsyncReaderWriterLock。
完整源码如下:
推荐阅读:
异步编程:同步基元对象(上)
异步编程:同步基元对象(下)
构建Async版本的同步基元系列已经全部翻译完,我希望你喜欢它。感谢大家的观看……赞的话请多帮推荐(*^_^*)
原文:《Building Async Coordination Primitives, Part 7: AsyncReaderWriterLock》
作者:Stephen Toub – MSFT
最近在学习.NET4.5关于“并行任务”的使用。“并行任务”有自己的同步机制,没有显示给出类似如旧版本的:事件等待句柄、信号量、lock、ReaderWriterLock……等同步基元对象,但我们可以沿溪这一编程习惯,那么这系列翻译就是给“并行任务”封装同步基元对象。翻译资源来源《(译)关于Async与Await的FAQ》
1. 构建Async同步基元,Part 1 AsyncManualResetEvent
2. 构建Async同步基元,Part 2 AsyncAutoResetEvent
3. 构建Async同步基元,Part 3 AsyncCountdownEvent
4. 构建Async同步基元,Part 4 AsyncBarrier
5. 构建Async同步基元,Part 5 AsyncSemaphore
6. 构建Async同步基元,Part 6 AsyncLock
7. 构建Async同步基元,Part 7 AsyncReaderWriterLock
源码:构建Async同步基元.rar
开始:构建Async同步基元,Part 7 AsyncReaderWriterLock
在上一篇文章中,我们构建了一个AsyncLock,本文,我将构建一个更高级的构造,一个异步版本的读写/锁。
异步版本的读写/锁比前几篇文章中所创建的同步基元要更加复杂。它包含更多的控制,这意味着需要更多决定来构建这个类型的精确行为。对于本例,我做了以下决定。首先,写操作比读操作拥有更高的优先级,即无论读操作或写操作请求的顺序,如果有写操作正在等待,它将得到优先于任何数量的读操作得到处理,即使它比那些读操作请求的晚些。第二,我决定不对读操作限流,即只要此时不存在未解决的写操作或等待着的写操作,所有读操作会立马被唤醒。
这是我们将构建的目标类型:
public class AsyncReaderWriterLock { public AsyncReaderWriterLock(); public Task<Releaser> ReaderLockAsync(); public Task<Releaser> WriterLockAsync(); public struct Releaser : IDisposable { public void Dispose(); } }
就像AsyncLock一样,我们使用一个实现IDiposable接口的Releaser结构,使AsyncReaderWriterLock类型能轻易用于一个范围,例如:
private readonly AsyncReaderWriterLock m_lock = new AsyncReaderWriterLock(); … using(var releaser = await m_lock.ReaderLockAsync()) { … // protected code here }
现在构建Releaser结构,我们使用一个bool值类型变量标识是否是写操作,因为我们需要使用不同的方式来唤醒两种操作的锁(优先处理写操作)。
public struct Releaser : IDisposable { private readonly AsyncReaderWriterLock m_toRelease; private readonly bool m_writer; internal Releaser(AsyncReaderWriterLock toRelease, bool writer) { m_toRelease = toRelease; m_writer = writer; } public void Dispose() { if (m_toRelease != null) { if (m_writer) m_toRelease.WriterRelease(); else m_toRelease.ReaderRelease(); } } }
因为AsyncReaderWriterLock比前几篇文章中所创建的同步基元要更加复杂,所以我需要更多成员变量。首先,我们为了提高性能,我为读操作的等待缓存了一个Task<Releaser>,同时也为写操作的等待缓存了一个Task<Releaser>以便立即完成。
private readonly Task<Releaser> m_readerReleaser; private readonly Task<Releaser> m_writerReleaser; public AsyncReaderWriterLock() { m_readerReleaser = Task.FromResult(new Releaser(this, false)); m_writerReleaser = Task.FromResult(new Releaser(this, true)); }
接下来,我需要为写操作维护一个等待队列,对于每一个写操作等待者都有对应的Task<CompletionSource>实例,因为我需要支持单独唤醒它们。同样也需要为读操作维护一个TaskCompletionSource<Releaser>实例。然而,对于读操作,按我们之前谈论的设计,当允许读操作运行时,就能让所有读操作一起运行,因此我只需要一个TaskCompletionSource<Releaser>实例。然而,因为我为读操作只维护了一个TaskCompletionSource<Releaser>实例,所以我还需要知道有多少个读操作正在等待,以便当我最终唤醒它们时,我能确保所有读操作被唤醒。
private readonly Queue<TaskCompletionSource<Releaser>> m_waitingWriters = new Queue<TaskCompletionSource<Releaser>>(); private TaskCompletionSource<Releaser> m_waitingReader = new TaskCompletionSource<Releaser>(); private int m_readersWaiting;
最后,我需要一个变量来维护锁的当前状态,它是一个整型,数值为0表示锁空闲;数值为-1表示一个写操作获取锁;正值表示一个或多个读操作获取锁。
private int m_status;
现在我们来实现4个方法:ReaderLockAsync, ReaderRelease, WriterLockAsync, and WriterRelease。(为了保证这4个方法数据的同步,我们首先对m_waitingWriters加锁)
ReaderLockAsync()方法用于读操作获取锁。在对m_waitingWriters加独占锁后,我们需要决定读操作是应该立即响应还是应该被迫等待。正如前面的决策,如果当前不存在等待的写操作或正在执行写操作,则读操作能立即得到响应,这种情况下,我们递增m_status计数并且返回为读操作缓存的TaskCompletionSource<Releaser>实例。如果当前存在等待的写操作或正在执行写操作,则我们强迫读操作等待,我们递增m_readersWaiting计数并且为读操作缓存的TaskCompletionSource<Releaser>实例添加延续任务并返回(延续任务确保所有的等待者能并发运行而不是串行化)。
public Task<Releaser> ReaderLockAsync() { lock (m_waitingWriters) { if (m_status >= 0 && m_waitingWriters.Count == 0) { ++m_status; return m_readerReleaser; } else { ++m_readersWaiting; return m_waitingReader.Task.ContinueWith(t => t.Result); } } }
WriterLockAsync()用于写操作获取锁。就像ReaderLockAsync()方法一样,需要对m_waitingWriters加独占锁,并且要考虑两种情况:写操作要么立即被响应,要么被迫等待。只有当前锁是空闲状态写操作才能立即被响应,因为写操作不能和任意读操作或其他写操作同时运行。所以,如果m_status值为0,我们更改m_status为-1表示现在正在运行一个写操作,并且返回为写操作缓存的Queue<TaskCompletionSource<Releaser>>队列。否则,我们为写操作创建一个新的TaskCompletionSource<Releaser>实例插入到队列中并且返回此实例对应的Task。
public Task<Releaser> WriterLockAsync() { lock (m_waitingWriters) { if (m_status == 0) { m_status = -1; return m_writerReleaser; } else { var waiter = new TaskCompletionSource<Releaser>(); m_waitingWriters.Enqueue(waiter); return waiter.Task; } } }
现在我们来构建唤醒功能,这些功能在被激活的读操作或写操作完成工作并且想释放它们持有的锁时被调用。ReaderRelease()需要递减读操作激活数计数,并且检查当前锁的状态。如果此时唤醒的是最后一个激活的读操作并且存在写操作正在等待,则会唤醒一个写操作并且设置m_status值为-1标识写操作获得锁。我们不需要检查任何等待的读操作,因为写操作比任何数量的读操作优先得到处理。如果此时没有任何等待的写操作,则任一后续请求的读操作将立即被响应。
private void ReaderRelease() { TaskCompletionSource<Releaser> toWake = null; lock (m_waitingWriters) { --m_status; if (m_status == 0 && m_waitingWriters.Count > 0) { m_status = -1; toWake = m_waitingWriters.Dequeue(); } } if (toWake != null) toWake.SetResult(new Releaser(this, true)); }
最后,我们构建WriterRelease()方法。当读操作完成时,如果等待队列中存在等待的写操作,我们从队列中取出一个写操作并且完成任务(因为将激活一个新的写操作,旧的写操作完成后,新的写操作会取代它的位置,所以不需要更新锁的状态m_status)。如果等待队列中不存在等待的写操作,但是此时存在等待的读操作,我们会唤醒所有读操作对应的任务,在这种情况下,我们还要为后续的读操作创建一个新的等待任务,并且需要更新m_status为当前激活的读操作数。如果没有任何读操作或写操作,则我们重置锁状态m_status。
private void WriterRelease() { TaskCompletionSource<Releaser> toWake = null; bool toWakeIsWriter = false; lock (m_waitingWriters) { if (m_waitingWriters.Count > 0) { toWake = m_waitingWriters.Dequeue(); toWakeIsWriter = true; } else if (m_readersWaiting > 0) { toWake = m_waitingReader; m_status = m_readersWaiting; m_readersWaiting = 0; m_waitingReader = new TaskCompletionSource<Releaser>(); } else m_status = 0; } if (toWake != null) toWake.SetResult(new Releaser(this, toWakeIsWriter)); }
这就是本节要讲的AsyncReaderWriterLock。
完整源码如下:
/// <summary>
/// Async版的 read/writer 锁
/// </summary>
public class AsyncReaderWriterLock
{
// 为了提高性能,我为读/写操作的等待各缓存了一个Task<Releaser>
private readonly Task<Releaser> m_readerReleaser;
private readonly Task<Releaser> m_writerReleaser;
// 写操作的等待队列
private readonly Queue<TaskCompletionSource<Releaser>> m_waitingWriters =
new Queue<TaskCompletionSource<Releaser>>();
// 读操作的等待任务
private TaskCompletionSource<Releaser> m_waitingReader =
new TaskCompletionSource<Releaser>();
// 当前有多少个等待着的读操作计数
private int m_readersWaiting;
// 维护锁的当前状态。0表示锁空闲;-1表示一个写操作获取锁;正值表示一个或多个读操作获取锁。
private int m_status;
public AsyncReaderWriterLock()
{
m_readerReleaser = Task.FromResult(new Releaser(this, false));
m_writerReleaser = Task.FromResult(new Releaser(this, true));
}
/// <summary>
/// 读操作获取锁
/// </summary>
public Task<Releaser> ReaderLockAsync()
{
lock (m_waitingWriters)
{
if (m_status >= 0 && m_waitingWriters.Count == 0)
{
++m_status;
return m_readerReleaser;
}
else
{
// 存在等待的写操作或正在执行写操作
++m_readersWaiting;
return m_waitingReader.Task.ContinueWith(t => t.Result);
}
}
}
/// <summary>
/// 释放读操作
/// </summary>
private void ReaderRelease()
{
TaskCompletionSource<Releaser> toWake = null;
lock (m_waitingWriters)
{
--m_status;
if (m_status == 0 && m_waitingWriters.Count > 0)
{
// 唤醒的是最后一个激活的读操作并且存在写操作正在等待
m_status = -1;
toWake = m_waitingWriters.Dequeue();
}
}
if (toWake != null)
toWake.SetResult(new Releaser(this, true));
}
/// <summary>
/// 写操作获取锁
/// </summary>
public Task<Releaser> WriterLockAsync()
{
lock (m_waitingWriters)
{
if (m_status == 0)
{
m_status = -1;
return m_writerReleaser;
}
else
{
// 新的写操作被迫等待
var waiter = new TaskCompletionSource<Releaser>();
m_waitingWriters.Enqueue(waiter);
return waiter.Task;
}
}
}
/// <summary>
/// 释放写操作
/// </summary>
private void WriterRelease() { TaskCompletionSource<Releaser> toWake = null; bool toWakeIsWriter = false; lock (m_waitingWriters) { if (m_waitingWriters.Count > 0) { toWake = m_waitingWriters.Dequeue(); toWakeIsWriter = true; } else if (m_readersWaiting > 0) { toWake = m_waitingReader; m_status = m_readersWaiting; m_readersWaiting = 0; m_waitingReader = new TaskCompletionSource<Releaser>(); } else m_status = 0; } if (toWake != null) toWake.SetResult(new Releaser(this, toWakeIsWriter)); }
public struct Releaser : IDisposable
{
private readonly AsyncReaderWriterLock m_toRelease;
// 变量标识是否是写操作,因为我们需要使用不同的方式来释放两种操作的锁
private readonly bool m_writer;
internal Releaser(AsyncReaderWriterLock toRelease, bool writer)
{
m_toRelease = toRelease;
m_writer = writer;
}
public void Dispose()
{
if (m_toRelease != null)
{
if (m_writer)
m_toRelease.WriterRelease();
else
m_toRelease.ReaderRelease();
}
}
}
}
/// <summary>
/// 示例:AsyncReaderWriterLock
/// </summary>
public class AsyncReaderWriterLockTest
{
public static async void Test()
{
AsyncReaderWriterLock m_lock = new AsyncReaderWriterLock();
using (var releaser = await m_lock.WriterLockAsync())
{
}
using (var releaser = await m_lock.ReaderLockAsync())
{
}
}
}
推荐阅读:
异步编程:同步基元对象(上)
异步编程:同步基元对象(下)
构建Async版本的同步基元系列已经全部翻译完,我希望你喜欢它。感谢大家的观看……赞的话请多帮推荐(*^_^*)
原文:《Building Async Coordination Primitives, Part 7: AsyncReaderWriterLock》
作者:Stephen Toub – MSFT
相关文章推荐
- (译)构建Async同步基元,Part 3 AsyncCountdownEvent
- (译)构建Async同步基元,Part 1 AsyncManualResetEvent
- (译)构建Async同步基元,Part 6 AsyncLock
- (译)构建Async同步基元,Part 5 AsyncSemaphore
- (译)构建Async同步基元,Part 2 AsyncAutoResetEvent
- (译)构建Async同步基元,Part 4 AsyncBarrier
- ReaderWriterLock(定义支持单个写线程和多个读线程的锁),Mutex(一个同步基元,也可用于进程间同步。 )
- ReaderWriterLock(定义支持单个写线程和多个读线程的锁),Mutex(一个同步基元,也可用于进程间同步。 )
- 混合线程同步核心篇——自定义混合同步锁,Monitor,lock,ReaderWriterLockSlim・・・
- Linux线程间同步 —— 读写锁(reader-writer lock)
- 同步ReaderWriterLockSlim
- 应用程序中的所有线程都可以访问方法中的公用字段。要同步对公用字段的访问,您可以使用属性替代字段,并使用 ReaderWriterLock 对象控制访问。为此,请按照下列步骤操作:
- .NET 同步与异步之锁(ReaderWriterLockSlim)(八)
- 多线程中的锁系统(二)-volatile、Interlocked、ReaderWriterLockSlim
- java中多线程模拟(多生产,多消费,Lock实现同步锁,替代synchronized同步代码块)
- [内核同步]自旋锁spin_lock、spin_lock_irq 和 spin_lock_irqsave 分析
- 锁对象Lock-同步问题更完美的处理方式
- JAVA多线程编程设计模式:Half-sync/Half-async(半同步/半异步)模式
- jQuery ajax 当async为false时解决同步操作失败的问题
- CentOS5.6构建本地源YUM服务并同步公网