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