We take code reviews very seriously in our group.  No checkin is ever made without a peer developer taking a close look.  (Incubation projects are often treated differently than product work, because the loss of agility is intolerable.)  A lot of this is done over email, but if there’s anything that is unclear from just looking at the code, a face to face review is done.  Feedback ranges from consistency (with guidelines and surrounding code), finding errors or overlooked conditions, providing suggestions on how to more clearly write something, comments, etc.; this ensures that our codebase is always of super high quality.

Concurrency adds some complexity to development, and requires special consideration during code reviews.  I thought I’d put some thoughts on paper about what I look for during concurrency-oriented code reviews, in hopes that it will be useful to anybody starting to sink their teeth into concurrency; it may also help you devise your own internal review guidelines.  Most of this advice just comes down to knowing a laundry list of best practices, but a lot of it is also knowing what to look for and where to spend your time during a review.

(A couple years ago I wrote a lengthy “Concurrency and its impact on reusable libraries” essay which provides a lot of the motivation behind what I look for.  It’s up on my blog, http://www.bluebytesoftware.com/blog/2006/10/26/ConcurrencyAndTheImpactOnReusableLibraries.aspx, and (though slightly out of date) I’m revising it for an Appendix in my upcoming book.  If you question why I believe something, chances are that this document will explain my rationale.  And it’s far more complete than this short essay; I’ve only hit the high points here.)

Getting started

I first review the code in a traditional sequential code review fashion.  When doing this, I earmark all state that I see as either “private” (aka isolated) or “shared”.  I then go back and closely review all state that is shared (accessible from many threads) with a fine-tooth comb.  Sometimes I’ll do this during my first pass through, but I usually find it helpful to understand the algorithmic structure of the changes first before fully developing an understanding of the concurrency parts.

Changes to existing code should be reviewed just as carefully (if not more carefully) as new code.  Concurrency behavior is subtle, and it’s very easy to accidentally violate some unchecked assumption the code was previously making.  Liberal use of asserts is therefore very important.  Sadly many of the conditions code assumes are simply unassertable (like “object X isn’t shared”).
I easily spend about 2x the amount of time reviewing the concurrency aspects of the code than usual sequential aspects.  Perhaps more.  This extra time is OK, because the concurrency portion is far smaller (in lines of code) than the sequential portion in most of the code I review.  There are obvious exceptions to this rule, especially since I’m on a team building low-level primitive data types whose sole purpose in life is to be used in concurrent apps.

Shared state and synchronization

Some state, although shared, is immutable (read-only) and can be safely shared and read from concurrently.  Often this is by construction (e.g. immutable value types) but sometimes this is by loose convention (e.g. a data structure is immutable for some period of time, simply by virtue of no threads actively writing to it).  Both should be clearly documented in the code.
Once mutable shared state is identified, I look for two major things:

1. When does it become shared, i.e. publicized, and what is the protocol for the transfer of ownership?  Is it done cleanly?  And is it well documented?
2. When does it once again become private again, if ever?  And is this documented too?

Ideally all shared state would have clean ownership transitions.  Any state that is disposable necessarily must have a point at the end of its life where it has a single owner, so it can be safely disposed of (unless ref-counting is used).  But for most state the line will be extremely blurry and unenforced.  Comments should be used to clarify, in gory detail.  I also tend to prefix names of variables that refer to shared objects with the word ‘shared’ itself, so that they jump out.

Many, many bugs arise from some code publicizing some state, sometimes by accident, and then continuing to treat it as though it is private.  It is also sometimes tricky to determine this precisely, since sharing can be modal.  A list data structure may be shared in some contexts but not others.  Knowing what its sharing policy is requires transitive knowledge of callers.  Building up this level of global understanding can involve a fair bit of simply sitting back and reading and rereading the code over and over again.

Once the policy around sharing a piece of state is known, it is crucial to understand the intended synchronization policy for that data.  Is it protected by a fine-grained monitor?  Is it manipulated and read in a lock-free way?  And so on.  And once the intended policy is known, is the actual policy implemented what was intended?

While this part is extremely important, by the way, I have to admit that I feel this aspect tends to overshadow other things in conversation.  This is probably because it’s the most obvious thing to look for.  Sadly the world of concurrency is far more subtle than this.  I’ve honestly found more bugs resulting from failing to identify shared state properly than resulting from failing to implement the synchronization logic itself properly.  Your mileage will of course vary.

Locks

I treat lock-based code and lock-free as two entirely separate beasts.  I spend about 5x the time reviewing lock-free code when compared to lock-based code.  There is a tax to having lock-free code in any codebase, so as you are reviewing it, also ask yourself: is there a better (or almost-as-good) way that this could have been done using locks?  Often the answer is no, due to the benefits lock-freedom brings (no thread can indefinitely starve another).

But if the answer is yes, that the code could be written more clearly using locks, you could save your team a lot of time by convincing the author to change his or her mind.  Not only is lock-free code far more difficult to write and test, it carries a large tax during long stress hauls and end-game bug-fixing, an important and time-sensitive period in the development lifecycle of any commercial software product.  Maintaining lock-free code also carries an extra long-term cost, particularly when ramping up new hires on it.  All of this risks interfering with your ability to work on cool new features at some point.  Don’t feel bad about pushing back on this one.  Hard.

Carefully review what happens inside of a lock region.  Look at every single line with scrutiny.

• Lock hold times should be as short as possible.  Hold times should be counted in dozens or hundreds of cycles, not thousands (unless absolutely unavoidable).
• If lock hold times are in the dozens, you can consider using a spin-lock.
• Recursive lock acquisitions are strongly discouraged.  If it can happen, did the developer clearly intend it to happen?  Or is this possibility accidental?  Point it out to them.  Also, are there any unexpected points at which reentrancy can occur?  E.g. any APC or message-pumping waits?  If yes, is there a way to avoid that by simple restructuring of the code?
• Dynamic method calls via delegates or virtual methods while a lock is held should be as rare as possible.  Method calls under a lock to user-supplied code should only ever happen if the concurrency behavior is clearly documented and specified for the user, and when invariants hold.  All of these cases can lead to reentrancy.  Often this requires special code to detect the reentrancy and respond intelligently.
• Lock regions should usually not span multiple methods: for example, acquiring the lock in one method, returning, and having the caller release it in another method is bad form.  It is very easy to screw up the control flow and deadlock your library.
• CERs can only use spin-locks currently (because Monitor.ReliableEnter is currently unavailable), if you care about orphaning locks at least (which most CER-cost does).  If you see somebody trying to write a CER using a CLR Monitor, their code is probably busted.  Thankfully CERs are pretty rare to encounter in practice.

Races that break code are always must-fix bugs, no matter how obscure.  If they happen with low frequency on the quad-cores of today, they will probably break with regularity on the 16-cores of tomorrow.  The kinds of code my team writes needs to remains correct and scale well into the distant future; presumably if you’re writing concurrent code already, yours does too.  If you find such a race, the code should not even be checked in until it’s fixed.  “But it only happens once in a while” is an inexcusable answer.  Benign races are OK but should be clearly documented.

Events

When I see any event-based code (either Monitor Wait/Pulse/PulseAll condition variables or some event type, like AutoResetEvent or ManualResetEvent), the first thing I do is build up a global understanding of all the conditions under which events are set, reset, and waited on.  This is to understand the coordination and flow of threads top-down, rather than bottom-up.  Because I’ve already reviewed the sequential parts of the algorithm, I typically already know the important state transitions events are guarding before I even get to this point.

Next, there are some simple aspects to specific usage of events that I look for:

• Understanding the relationship between mutual exclusion, the state, and the events is important and subtle.  Comments should be used ideally to explain that.
• Does the setting of the event happen in a wake-one (Pulse, Auto-Reset) or wake-all (PulseAll, Manual-Reset) manner?  If it’s wake-one, are all waiters homogeneous?  Is it always strictly true that waking-one is sufficient and won’t lead to missed wake-ups?
• Waiters that release the lock and then wait should be viewed with suspicion.  There’s a race between the release and wait that notoriously causes deadlocks.
• Concurrent code should never use timeouts as a way to work around sloppiness in the way threads wait and signal.  A missed wake-up is a bug in the code that must be fixed.

Lock-freedom and volatiles

If you’re looking at lock-free code, you need to have a firm grasp on the CLR’s memory model.  See http://www.bluebytesoftware.com/blog/2007/11/10/CLR20MemoryModel.aspx for an overview.  Don’t think about the machine, think about the logical abstraction provided by the memory model.  You also need a firm grasp on the invariants of the data structures involved.  Specifically you are looking to see if the structure could ever move into a state, visible by another thread, where one of these invariants doesn’t hold.  I explicitly permute (often on a whiteboard or in notepad) the sections of the code that involve shared loads and stores, using knowledge of the legal reorderings given our memory model, to see if the code breaks.

Any variable marked as volatile should be a red flag to carefully review all use of that variable.  For every single read and every single write of that variable, you must look at it and convince yourself of why volatile is necessary.  If you can’t, ask the person who wrote the code.  Sometimes volatile is used because most (but not all) call sites need it; that’s often acceptable.  Leaving the variable as non-volatile and selectively using Thread.VolatileRead for the reads that need it is typically too costly.  Anyway, comments should always be used to explain why each load and store is volatile, even if it doesn’t strictly need the volatile semantics.

Conversely, any variable that is apparently shared, but not marked volatile, should be an even redder flag.  It’s very likely that this is a mistake.  Recall that writes happen in-order with the CLR’s memory model, but that reads do not.  Anytime there is a relationship between multiple shared variables that are written and read together (without the protection of a lock), they typically both need to be volatile.

Any reads of shared variables used in a tight loop must be marked volatile.  Otherwise the compiler may decide to hoist them, causing an infinite loop.  Even if they are retrieved via simple method calls like property accessors (due to inlining).

Thread.MemoryBarrier should typically only occur to deal with store (release) followed by load (acquire) reordering problems.  And it’s usually a better idea to use an InterlockedExchange for the store instead, since it implies a full barrier but combines the write.  Sometimes a fence can be used to flush write buffers—like when releasing a spin-lock to avoid giving the calling thread the unfair ability to turn right around and reacquire it—but this is extremely rare, and often an indication that somebody has an inaccurate mental model of what the fence is meant to do.

Custom spin waiting should be used rarely.  If you see it used, the person may not be aware that spin waits need special attention: to work well on HT machines, yield properly to all runnable threads with appropriate amortized costs, to spin only for a reasonable amount of time (in other words, less than the duration of a context switch), and so on.  Thread.SpinWait does not do what most people expect, since it only covers the first.  Kindly let them know about these things.  If any spin waiting is used in a codebase, it’s far better to consolidate all usage into a single primitive that does it all.

Wrapping up

At the end of each review, ask yourself whether all of the concurrency-oriented parts of the code were clearly explained in the design doc for the feature.  Did this carry over to clearly written comments in the implementation?  These are some really hard issues to get your head around, so the time spent reviewing the code should not be lost.  Somebody, someday down the road, will need to understand the code again (perhaps so that they can maintain it, test it, etc.), and it is your responsibility as a member of the team—regardless of whether you wrote the code—to do your part in making that feasible.  You should explicitly go back to the design doc and suggest areas for clarification.

A few of us got in a room two weeks ago with Charles to discuss the Task Parallel Library component of Parallel Extensions.

It's now available on Channel9: http://channel9.msdn.com/Showpost.aspx?postid=384229.

A long time ago, I wrote that you’d never need to write another finalizer again.  I’m sorry to say, my friends, that I may have (unintentionally) lied.  In my defense, the blog title where I proclaimed this fact did end with “well, almost never.”

Finalizers have historically been used to ensure reclamation of resources that are finite or outside of the purview of the CLR’s GC.  Native memory and Windows kernel HANDLEs immediately come to mind.  Without a finalizer, resources would leak; server apps would die, client apps would page like crazy, and life would be a mess.  For such resources, properly authored frameworks also provide IDisposable implementations to eagerly and deterministically reclaim the resources when they are definitely done.  Three years ago, I wrote a lengthy treatise on the subject.

The finalizer is there as a backstop.  It is often meant to clean up after bugs , such as when a developer forgets to call Dispose in the first place, tried to but failed due to some runtime execution path skipping it (often exceptions-related), or a framework or library author hasn’t respect the transitive IDisposable rule, meaning that eager reclamation isn’t even possible.  It also avoids tricky ref-counting situations as are prevalent in native code:  since the GC handles tracking references, you, the programmer, can avoid needing to worry about such low-level mechanics.  In all honesty, the finalizer’s main purpose is probably that we wanted to facilitate a RAD and VB-like development experience on .NET, where programmers don’t need to think about resource management at all, unlike C++ where it’s in your face.  While one could reasonable argue that IDisposable is all you need (the C++ argument), that would have gone against this goal.

Concurrency changes things a little bit.  A thread is just another resource outside of the purview of the CLR’s GC, and is actually backed by a kernel object and associated resources like non-pageable memory for the kernel stack, some data for the TEB and TLS, and 1MB of user-mode stack, to name a few.  They also add pressure to the thread scheduler.  Threads are fairly expensive to keep around, and “user” code is responsible for creating and destroying them.

Now, it’s true that we are moving towards a world where threads and logical tasks are not one and the same.  This is a ThreadPool model.  But it’s also true that a task that is running on a thread is effectively keeping that thread alive, and perhaps more concerning, preventing other tasks from running on it.  Use of a resource is a kind of actual resource itself, although more difficult to quantify.

So, what does all of this have to do with finalization?

If some object kicks off a bunch of asynchronous work and then becomes garbage—i.e. the consumer of that object no longer needs to access it’s information—then it’s possible (or even likely) that any outstanding asynchronous operations ought to be killed as soon as possible.  Otherwise they will continue to use up system resources (like threads, the CPU, IO, system locks, virtual memory, and so on), all in the name of producing results that will never be needed.  The only reason this task stays alive is because the scheduler itself has a reference to it.

Just as with everything discussed above pertaining to non-GC resources, we’d like it to be the case that such a component would offer two methods of cleanup:

1. Dispose: to get rid of associated asynchronous computations immediately when the caller knows they no longer need the object.
2. Finalization: to get rid of associated resources that are still outstanding when the GC collects the root object that is responsible for managing those asynchronous computations.

You’ll notice that we support cancelation in a first class and deeply-ingrained way in the Task Parallel Library.  While not exposed in PLINQ (yet), there is actually cancelation support built-in (though not as fundamental as we’d like (yet)).  This is a useful hook to allow us to build support for both resource reclamation models.  In this sense, cancelation as a pattern of stopping expensive things from happening is quite similar to resource cleanup.  Clearly they aren't identical, but we will need to figure out the specific deltas.

I should also point out that we will prefer and push structured parallelism for many reasons.  Parallel.For is an example, where the API looks synchronous but is internally highly parallel.  One reason we like this model is that the point at which concurrency begins and ends is very specific.  The call won’t return until all work is accounted for and completed.  It’s only when you bleed computations into the background after a call returns that everything stated above becomes an issue.  This is obviously nice for failures (e.g. you are forced to deal with them right away), but also because it alleviates this problem nicely.

I don’t think we’re at a point where we can recommend definite tried-and-true best practices for cancelation of asynchronous work and how it pertains to resource management.  I do think we need to get there by the time we ship Parallel Extensions V1.0.  And I think we will.  Here’s a snapshot summary of my current thinking, however, and I would love to get feedback on it:

1. We should tell people to implement IDisposable and to Cancel tasks inside Dispose, when their classes own unstructured asynchronous computations.
2. We may or may not want people to implement a finalizer to do the same.  I currently believe we will.
3. I am undecided about whether these cancelations should be synchronous.  In some sense, they should be since you’d like to know that all resources have definitely been reclaimed.  But this would mean blocking (possibly indefinitely) on the finalizer thread.  That’s a definite no-no.  Blocking in Dispose would mean blocking (possibly indefinitely) inside a finally block.  That’s also a no-no, although it’s less severe of one than the finalizer.  It just means hosts can’t take over threads as easily when they need to abort them.  Thankfully we offer the Task.Cancel method which is non-blocking.  Possibly we should suggest synchronous cancelation inside of Dispose, and asynchronous inside of the finalizer.
4. If we did do synchronous anywhere, presumably with Task.CancelAndWait, we’d need to recommend a practice for communicating failures.  Throwing from Dispose is discouraged, but so is swallowing failures.  The kind of code usually run inside of Dispose is much less likely to generate exceptions than running arbitrary tasks full of user code.  Catch-22.
5. There are some cases we can do the cancelation thing ourselves.  Whether we do or not is subject to debate, but I believe we should.  If we ensured the scheduler’s references are weak, then once all other code in the process drops the reference, we would not schedule it.  This implies that tasks are seldom executed “for effect”, which is certainly a judgment call.  It might be worth exposing an option that allows “for effect” tasks to be created not subject to this rule.
6. The trickiest case is when a task is already running.  For short-running tasks, this may not be a huge concern, but a lot of such tasks do recursively queue up additional ones.  It would be nice if the fact that its results are no longer needed somehow flowed automatically to the task, perhaps through cancelation.   This also means waking tasks from blocking calls.

It’s interesting to point out that 5 and 6 were part of the original motivation for the inventors of the future abstraction.  They noted that representing computations as futures, and allowing the GC to collect them before they run once they’ve become unreachable, effectively makes computations garbage-collectable.  This, I think, is a neat idea, particularly if your program uses futures pervasively.

In any case, I wanted to point these subtleties out, and hear any feedback folks out there might have.  What I find particularly interesting about concurrency, as we move forward on things like Parallel Extensions, is that there are a lot of subtle implications to the way programs are written.  This includes fundamental things like exceptions and resource management.  There are other subtle impacts, like whether the ordering of results coming out of a computation matters.  PLINQ surfaced this early on, and I didn’t expect the pervasive nature of the issue.   Debugging and profiling are also extraordinarily different.  I suspect we’ll continue running into many such things throughout the evolution to highly parallel software.

A couple weeks back, we started filming a bunch of Channel9 videos about various aspects of the Parallel Computing team.  This is the larger team responsible for Parallel Extensions to .NET, among other things.  We'll of course spend some time on Parallel Extensions in upcoming videos.

But who better to kick it off than Burton Smith, a legend in the parallel computing arena?

On General Purpose Supercomputing and the History and Future of Parallelism
http://channel9.msdn.com/Showpost.aspx?postid=382639

Burton's the kind of guy that you run into when meandering the hallways, have a 5 minute conversation, and walk away with at least 20 relevant and fascinating papers on parallel computing to go off and read.  But now instead of reading 20 papers, you can just go watch the video.

Torn reads are possible whenever you read a shared value without synchronization that is either misaligned and/or which spans an addressible pointer-sized region of memory.  This can lead to crashes and data corruption due to bogus values being seen.  If not careful, torn reads can also violate type safety.  If you have a static variable that points to an object of type T, and your program only ever writes references to objects of type T into it, you may still end up accessing a memory location that isn't actually a T.  How could this be?

You guessed it.  Torn reads apply to pointer values just as much as they do to ordinary values.  So a thread reading a pointer in-flux could see bits of its value in separate pieces, blending the state before and after the update.  Dereferencing this mutant pointer would lead you off into an unknown place in the address space, and most certainly not to an instance of T, breaking type safety.  Since VC++ aligns pointer fields automatically, you'd have to go out of your way with __declspec(align(N)) or an unaligned allocator to create this situation.  Similarly with .NET's StructLayoutAttribute.  Moreover, it turns out that .NET guards against this problem in its type loader, by rejecting any types containing improperly aligned object references.  This is good news, because otherwise a plethora of security vulnerabilities would be possible.  But VC++ doesn't offer any such guarantees.

This is another example where trying to program in a lock-free manner can lead to difficulties that aren't present when you stick to ordinary locking.

I'm still plugging away at my new concurrency book.

The fact that we have cover art and that it's available for pre-order on Amazon are both great signs that it's getting close to being done:

The full TOC (as of right now) is available here.  A few chapters are still in the works, and there's a bit of editing ahead.  I've also decided to write Appendices on PFX and CCR.  In the meantime, definitely feel free to pick up a PDF of some early content via RoughCuts.  Believe it or not, this is a way to provide real-time feedback that can impact the book before it hits the presses.

I have to say this is the most complicated piece of writing I've ever undertaken.  Not only does the material require going very deep in a lot of hard areas, but I've noticed that as a community we're learning to speak speak better and to use consistent terminology about various aspects of concurrency.  To stay relevant, I'm finding a fair bit of content has had to be reworked several times.

At the same time, and from a selfish standpoint, this book has been a wonderful forcing function to learn everything there is to know about concurrency.  Not that this is a realistic goal, mind you, but gosh darnit I'm trying.  I'm convinced at this point that the best way to become an expert on something is to try to teach it to other people.  And what better way than writing a book?  If you can't explain it clearly to a broad, on-the-average-less-expert-than-you audience, you probably have a faulty mental model to begin with.  The process of merely trying usually reveals this.  I encourage everybody out there to try it.  At least once.

Most schedulers try to keep the number of runnable threads (within a certain context) equal to the number of processors available.  Aside from fairness desires, there’s usually little reason to have more: and in fact, having more can lead to more memory pressure due to the cost of stacks and working set held on the stacks, non-pageable kernel memory, per-thread data structures, etc., and also has execution time costs due to increased pressure on the kernel scheduler, more frequent context switches, and poor locality due to threads being swapped in and out of processors.  In extreme cases, blocked threads can build up only for all of them to be awoken and released to wreak havoc on the system at once, hurting scalability.

A naïve approach of one-thread-per-processor works great until a thread on one of these processors blocks, either “silently” as a result of a pagefault or “explicitly” due to IO or a synchronization wait.  (I should mention that due to the plethora of hidden blocking calls in the kernel, Win32 user-mode code, and the .NET Framework, a lot of IO and synchronization waiting is “silent” too.)  In this case, a processor becomes idle (0% utilization) for some period of time.  If there is other work that could be happening instead, this is clearly bad.

Many programs spend most of their time blocked.

Four particular solutions to this problem are commonplace on Windows:

1. Create more threads than processors and hope for the best.  This trades some amount of runtime efficiency for the insurance that processor time won’t go to waste.
2. Periodically poll for blocked threads using some kind of daemon and respond to the presence of one by creating a new thread to execute work.  Eventually this thread would go away, for instance when the blocked thread awakens.  This is the approach used by the CLR ThreadPool, although it caps the total.  (The TPL uses this appraoch today also, but we're changing/augmenting it.)  For obvious reasons, this approach is quite flawed: you easily end up with more running threads than processors, have to trade-off more frequent polling--which implies more runtime overhead--with less frequent polling--which adds time to the latency in the scheduler’s response to a blocked thread.
3. Block on an IO Completion Port at periodic intervals--e.g. when dispatching a new work item in a ThreadPool-like thing--which has the effect of throttling running threads.  This still requires creating more threads than processors, but helps to ensure few of them run at the same time.  Unfortunately, it still does lead to more of them actually running than you’d like since the port can only prevent a thread from running when it goes back and blocks on the port in the kernel.  But this is only done periodically.
4. Specialized systems like SQL have used Fibers in the past to avoid needing full-fledged threads to replace the blocking ones.  To do this, they ensure all blocking goes through a cooperative layer, which notifies a user-mode scheduler (UMS).  The user-mode scheduler maintains a list of blocked Fibers, but can multiplex runnable Fibers onto threads, keeping the number of threads equal to the number of processors.  A thread effectively never blocks, Fibers do, but this requires all blocking to notify the UMS.  Aside from extraordinarily closed world systems, this approach doesn’t usually work.  That’s because Fibers are not threads and multiplexing entirely different contexts of work onto a shared pool of threads (at blocking points) can easily lead to thread affinity nightmares.

The CLR facilities #4 by funneling all synchronization waits in managed code through one point in the VM codebase.  This was done initially to ensure consistent message pumping on STA threads, via CoWaitForMultipleHandles.  But it was then exploited in 2.0 to expand the CLR Hosting APIs to enable custom hosts to hook all synchronization calls.  This is convenient for building interesting debugging tools, like deadlock detecting hosts.

A fifth approach is often viable and even preferable, and that is to avoid blocking altogether.  Often referred to as continuation passing style (CPS), the idea is that, where you’d normally have blocked, the callstack is transformed into a resumable continuation.  For an example of this, look at Jeff Richter’s ReaderWriterLockGate class: it’s a reader/writer lock with no blocking.  Asynchronous IO is supported by files and sockets on Windows, and enables a similar style of programming.  The continuation is ordinarily just a closure object that has enough state to restart itself when the sought-after condition arises.  When it does arise, the continuation is scheduled on something like the CLR ThreadPool.  This avoids burning any threads while the wait occurs.

For obvious reasons, CPS is usually hard to achieve in .NET: there is no language support for first class continuations in .NET, all synchronization primitives are wait-based, and keeping a whole stack around in memory would be a terrible idea anyway.  You’d also need to worry about resources held on the stack, including locks.  Instead, you should save only that state which is needed during the continuation.  In a message passing system this is much simpler, since most of the program is full of continuations in the form of message handlers.  For an example of such a system, check out the Concurrent and Coordination Runtime (CCR) and/or Erlang.

Even in message passing systems, it’s impossible to escape the fundamental blocking issue, since it is platform-wide.  And in ordinary imperative programs, the CPS transformation is near-impossible at the leaves of callstacks: unless you have whole program knowledge, who knows what your caller expects?  Most APIs are synchronous.  Futures and Promises potentially make this style of programming easier, though in the extreme all APIs would need to return a Promise rather than a true value.

Nothing conclusive, just some random thoughts ...