摘要:短評：並行程式設計的衝擊與挑戰
依據摘錄自Software and the Concurrency Revolution[1]的《並行程式設計的衝擊與挑戰》[2]一文的三個要點，我個人的淺見如下：
第一、並行程式設計既然可以提高效能，為何不願意嘗試使用並行程式設計分析並行程式設計？
第二、同時執行context-sensitive analysis[3]與synchronization analysis[4]並非不可行。以Microsoft .Net TPL為例，步驟如下：
1、在開發工具撰寫擴充模組，協助程式碼編輯器於編輯時期進行步驟二與步驟三。
2、釐清各個Task的執行先後順序，並且列出各種排列組合。
3、面對Explicity Inline[5](以同步為優先考量的Task.RunSynchronous)與Implicity Inline(倘若其他的Thread為閒置狀態，以非同步為優先考量)，必須將各種可能的情形與衍生的變化納入考量，因此將會導致步驟一的排列組合的變化數量大幅增加。
4、在執行時期，面對Task的八種TaskStatus[6]，其中有三種(Canceled、Faulted與RanToCompletion)的任何其中一種是Task的最終狀態，可以透過Log檔案詳加記錄相關的細節。
只要能在編輯時期，將步驟二與步驟三推演的各種Task的執行順序的排列組合一一編號成為各種劇本，再逐一執行或者抽樣執行(例如使用啟發式演算法)，並且追蹤與分析步驟四產生的異常情形，將有可能找到逐步改善的規則，並且為客製化的scheduler[7]最佳化。
第三、倘若前述第二點可行(暫時不論專案規模大小或者不考慮Task之中是否包含其他的Task，如Attached與Detached Child Task[8])，只要盡可能地將Task切割，減少每一個Task內部的程式碼，讓每一個Task專注在一個焦點之上，就可以減少程式設計師閱讀程式碼的負擔。
綜合前述三點，倘若預設立場認為同時執行context-sensitive analysis與synchronization analysis不可行，如何為客製化的scheduler最佳化？
[1]Software and the Concurrency Revolution
http://dl.acm.org/citation.cfm?id=1095421
[2]並行程式設計的衝擊與挑戰
http://www.dotblogs.com.tw/kylessukaichang/archive/2014/09/22/146663.aspx
[3]context-sensitive analysis
http://en.wikipedia.org/wiki/Data-flow_analysis#Forward_Analysis
[4]synchronization analysis
http://en.wikipedia.org/wiki/Synchronization
[5]Task.Wait and “Inlining”
http://blogs.msdn.com/b/pfxteam/archive/2009/10/15/9907713.aspx
[6]TaskStatus Enumeration
http://msdn.microsoft.com/zh-tw/library/system.threading.tasks.taskstatus(v=vs.110).aspx
[7]TaskScheduler Class
http://msdn.microsoft.com/zh-tw/library/system.threading.tasks.taskscheduler(v=vs.110).aspx
[8]Attached and Detached Child Tasks
http://msdn.microsoft.com/en-us/library/vstudio/dd997417(v=vs.110).aspx