--- a/src/parallel_execution/Todo	Thu Jan 16 15:11:11 2020 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,144 +0,0 @@
-Fri May  4 20:06:48 JST 2018
-
-    par goto がある code segment は $inParGoto ではなく $hasParGoto にする
-    par goto があるばあいは goto meta ではなく goto parGotoMeta にする
-    taskList の処理も parGotoMeta で行う
-    
-    par goto の遅い理由を調べる
-        多分 Context と Synchronized Queue の生成に時間がかかってる？
-    
-    Perl スクリプトを一つにする
-    Context を生成するモジュールとstubを生成するモジュールをそれぞれオブジェクトとして作る
-    
-    Code Gear のプロトタイプを格納するオブジェクトをつくる
-
-Tue Aug  1 19:32:55 JST 2017
- 
-    DataGear の待ち合わせ
-    DataGear の Commit
-     
-    これらは、stubとgoto meta の部分で行う
-    
-    どれに対して行うかを実行時あるいはコンパイル時に指定する必要がある
-
-    一つの解決策は、 typedefのときにannotution してあげる
-    もう一つの解決策は, Data Gear の allocation 時に指定する
-    Code Gearのプロトタイプのなかで指定する事も考えられる
-    
-    par goto時に渡す continuation で同期をとっても良い, このときにはこのcontinuation を作成するinterfaceを作る必要がある
-
-    実行時に指定してしまうと、毎回フラグのチェックが必要になる。
-    これを abstract model checking を事前に行うことで, static なコードに置き換える事はできる
-
-    例題としては, chat、dining philosophers, map reduce
-
-Fri Apr 14 18:44:09 JST 2017
-
-    struct B {
-        A a;
-        .....
-    }
-    struct A {
-        __code init(..., __code next(A a, ...));
-    }
-    par goto A->init(a);
-    // meta level
-    task->code = C_init_A;
-    task->data[idg] = ...;
-    task->data[idg + 1] = ...;
-    task->data[odg] = ...;
-    task->next = C_writeToa;
-    goto meta(context, context->TaskManager->spawn)
-
-    // lambda version?
-    par goto A->init(\A -> a = A)
-
-    // meta level
-    par goto A->init(next = \A -> a = A)
-
-Wed Mar  1 18:25:36 JST 2017
-
-    parallel_executtion/test/ を .cbc に書き直す
-    rb_tree の stub をできるだけ取り外す
-    synchornizedQueue の meta部分を分離する
-    synchronizedQueue のバグをとる
-    GPU のバグとり
-    cbc++...?
-
-Sat Jan 28 16:10:28 JST 2017
-
-    stackからpopした後、呼び出される continuation は出力を受けとる。
-    出力を受けとる stub を生成する必要がある。
-    なので、CodeGear が、そのような interface で定義されたものかどうかを調べる必要がある。
-    Stackのnext(やisEmpty)に代入された時点でわかる。なので、あまり自明な見つける方法がない。 
-    引数の異なるnextは異なる名前を持つべきか? 持たなくてもできるが...
-
-         goto next(data, ...);                                       引数で渡された continuation に移動
-         goto nodeStack->push(newNode, replaceNode1);                Interface の呼び出し。(ここで replaceNode1 が stack の戻り値を受けることがわかる。
-         goto replaceNode(traverse, traverse->current, newNode);     普通のgoto
-         goto rotateTree->next(...);                                 DataGearに格納された continuation
-
-    などをチェックする必要がある。これらの型チェックは CbC level では行われない。(CbCはmeta levelだから)
-
-     戻り値の部分は interface に記述させるという手もあるな。
-
-
-Sun Jan 22 20:11:28 JST 2017
-
-    TaskManagerから必要なCPUWorkerを生成する
-    WorkerはcreateWorker時に新しくthreadを作る
-    
-    TaskManager->createTaskで新しいContextを生成する
-    この時点でWorkerを番号で指定する
-    このContextにGearefで値を設定していく
-    待ち合わせ用のDSを設定する
-    taskManager->spawnでWorkerにcontextを送る
-
-Fri Jan 13 17:47:40 JST 2017
-
-    Task は contextを直接使うことにする
-        DS には, まっているcontextをListを作る
-        context に実行中断中のCS の番号をいれるフィールドを用意する
-        待っているDS のcount
-    createTaskの手順
-        新しくcontextを作る
-            allocate 用のheap も用意
-            もとのcontextを全部copyする or 必要なものだけcopyする
-            待ち合わせのDS群を指定する
-            終わったあとの行き先を指定する(default は task_exit)
-            exception の行き先も必要な指定する
-            待っているDSが全部揃っていたら active Queueに入れる
-    task の実行
-        taskの実行後、 goto meta する直前で code gear commit を呼んで, Reader list を消化する
-        複数から参照されるDSは一旦localに書き出して, その後atomic に書き出す
-        複数から参照されるDSは何かしら宣言が必要
-            つまり DS には 一つ一つ owner がいる
-
-Mon Nov 28 17:39:39 JST 2016
-
-    Task,TaskManager,Workerのインターフェースの実装を作成する
-    Taskを一旦Treeに入れずに直接Queueに入れる
-
-    Task
-        CodeGen
-            IDataSeg
-            IDataSeg
-            ...
-        idsCount
-        nextTask(can be C_exit)
-            ODataSeg?
-
-    TaskManager
-        createWorker
-        spawn (any,cpu,GPU)
-        taskSend
-        activeQueue
-        shutdown
-        deadlockDetectid
-
-    SynchronizedQueue * Workerの数だけ
-
-    Worker
-        execute
-        taskRecive
-        shutdown