Asynchrony in C# 5 Part Five: Too many tasks

re: Asynchrony in C# 5 Part Five: Too many tasks

MZ — Fri, 19 Nov 2010 14:20:00 GMT

Yes it certainly does. Still CLR unlike JVM does evolve (example: con- and contra- variance in 4.0) so that shouldn't be a blocker.

Though your point is well-taken, I note that generic variance was added to the CLR in v2, not v4. No mainstream languages took advantage of that feature until C# 4.0 and VB 10, but it has been there since generics were implemented in the first place. - Eric

re: Asynchrony in C# 5 Part Five: Too many tasks

Gabe — Wed, 10 Nov 2010 15:47:36 GMT

MZ: Doesn't the use of tasklets require modifications to the CLR? Granted, I'm all for modifying the CLR to support that...

re: Asynchrony in C# 5 Part Five: Too many tasks

MZ — Wed, 10 Nov 2010 10:16:52 GMT

Followup: Coroutine implementation

bugzillafiles.novell.org/attachment.cgi

re: Asynchrony in C# 5 Part Five: Too many tasks

MZ — Wed, 10 Nov 2010 10:13:11 GMT

Have you considered replicating Mono's coroutine approach?

www.mono-project.com/Continuations

Apart from still being buggy in Mono, this allows for easy suspension of function execution.

No need to expand into a state machine.

My sample implementation of coroutines usting tasklets (circa 50 lines of code):

bugzillafiles.novell.org/attachment.cgi

(did I mention, it's still buggy? :P)

re: Asynchrony in C# 5 Part Five: Too many tasks

Stuart — Tue, 09 Nov 2010 22:49:25 GMT

How about just bump people back to the front of the queue if the teller is unable to finish servicing their request due to lack of bills? Given that we're using the W system (one shared queue) that should work fine as long as we have a way for the tellers to skip people that they know in advance they can't service.

re: Asynchrony in C# 5 Part Five: Too many tasks

Aaron G — Tue, 09 Nov 2010 21:29:05 GMT

You kind of left out the punchline - what's the *correct* approach to this situation, in either the bank analogy or the world of asynchrony?

My guess is that you would send each client into some sort of limited "wait pool" (waiting area?) every time they need to wait on I/O (or the gofer), and whenever the I/O thread (gofer) comes back, you make a note to check the pool after the current request is done and finish off whatever you can. Presumably if the pool has a limited size then eventually the line will start to snake out the door again if you get too busy.

But, maybe this is way too simplistic an approach, or too close in concept to the warehouse situation. Is there a better way?

re: Asynchrony in C# 5 Part Five: Too many tasks

Rob Reckless — Tue, 09 Nov 2010 08:00:07 GMT

AN excellent blog on Asynchrony!

Rob Reckless - RecklessDevelopment

www.recklessdevelopment.com

re: Asynchrony in C# 5 Part Five: Too many tasks

Gabe — Tue, 09 Nov 2010 06:50:15 GMT

I think typing 100 wpm is nearly 10 keystrokes per second. It's hard to imagine somebody typing that fast for long enough that a few garbage objects for every keystroke could cause enough memory pressure to make a noticeable performance difference. Clearly making a single timer that gets reset on each keystroke was the right decision, but it's still hard to imagine that creating 10 timers per second for brief periods causes performance problems.

BTW, using the W style of queueing is the right thing to do here because then the line doesn't stall unless all the tellers are asleep waiting for the gofer. And if more tellers can open up their stations when too many other tellers are waiting for the gofer, the line will never stall until the bank runs out of teller stations.

re: Asynchrony in C# 5 Part Five: Too many tasks

Gaurav — Tue, 09 Nov 2010 04:42:04 GMT

The more I learn about implementations of asynchrony the more I love it.

"More thoughts on syntactic concerns" desperately waiting :)

re: Asynchrony in C# 5 Part Five: Too many tasks

Frank Quednau — Mon, 08 Nov 2010 20:44:55 GMT

The Rx design guidelines show a similar situation of capturing keystrokes and kicking off a dictionary search. However, they use a Throttle which appears to be a more clever approach this time round :)