Building Async Coordination Primitives, Part 1: AsyncManualResetEvent

re: Building Async Coordination Primitives, Part 1: AsyncManualResetEvent

Stephen Toub - MSFT — Thu, 24 May 2012 15:56:27 GMT

Hi Upsilon-

I'm glad you enjoyed the series. Regarding Reset, it just depends on how aggressive you want the method to be, e.g. if you're ok with Reset being less aggressive (which functionally should be fine), you could remove the while, but you still do need the interlocked.

re: Building Async Coordination Primitives, Part 1: AsyncManualResetEvent

Upsilon Chen — Thu, 24 May 2012 14:40:05 GMT

Hi Stephen,

Thanks for these inspiring articles!

I got a question about the Reset() part of the sample code:

why do we need the "while" statement?

According to the code, the only chance to repeat the process in the "while" block is when "tcs" is not equal to "m_tcs", and that means there is another thread called "Reset" and assigned a new instance to "m_tcs". In such case, is there any problem if we just return the "Reset" call and not do the process in the "while" block again?

re: Building Async Coordination Primitives, Part 1: AsyncManualResetEvent

Stephen Toub - MSFT — Tue, 21 Feb 2012 16:54:43 GMT

Hi Gregory-

I'm glad you like the content. And thanks for the suggestion; I'll keep that in mind for future posts.

re: Building Async Coordination Primitives, Part 1: AsyncManualResetEvent

Gregory Chernis — Tue, 21 Feb 2012 15:21:27 GMT

Stephen,

Great content, as always.

May I propose using locks to protect the TaskCompletionSource member field? It might better serve the general audience, without muddying up the issue with volatile and Interlocked. Your approach feels like a solution that was optimized for performance.

It would also be instructional to see how such code is tested.