Linux高性能ネットワーク:コプロセッサシリーズ07-コプロセッサ実装の定義


目次
  • Linux高性能ネットワーク:コパスシリーズ01-前言
  • Linux高性能ネットワーク:コプロセッサシリーズ02-コプロセッサの起源
  • Linux高性能ネットワーク:コプロセッサシリーズ03-コプロセッサのケース
  • Linux高性能ネットワーク:コラボレーションシリーズ04-コラボレーション実現の動作原理
  • Linux高性能ネットワーク:コプロセッサシリーズ05-コプロセッサ実現の原語操作
  • Linux高性能ネットワーク:コモンシップシリーズ06-コモンシップ実現の切り替え
  • Linux高性能ネットワーク:コプロセッサシリーズ07-コプロセッサ実装の定義
  • Linux高性能ネットワーク:コプロセッサシリーズ08-コプロセッサ実装スケジューラ
  • Linux高性能ネットワーク:コプロセッサシリーズ09-コプロセッサ性能テスト
  • [Linux高性能ネットワーク:コモンシップシリーズ10継続]()
  • 7.協力実現の定義
  • 7.0前言
  • 7.1運転体は、
  • を様々な状態の集合で効率的に交換する方法について説明する.
  • 7.2スケジューラとコモンの機能限界
  • 7.0はじめに
      問題:協程はどのように定義しますか?スケジューラはどのように定義しますか?  まず1つの設計問題:  設計1つの協働する運転体Rと運転体スケジューラSの構造体  1.実行体R:実行状態{準備完了、スリープ、待機}を含む、実行体コールバック関数、コールバックパラメータ、スタックポインタ、スタックサイズ、現在の実行体2.スケジューラS:実行セット{準備完了,睡眠,待機} という設計問題を含めて2つの問題を分割し,1つの運転体がどのように効率的に複数の状態でセットを交換するかを含む.スケジューラと運転体の機能限界.
    7.1運転体を効率的に複数の状態セットで交換する方法
     新しく作成したコヒーレンスは、作成が完了したら、準備完了セットに追加し、スケジューラのスケジューリングを待つ.協程は運行が完了した後、IO操作を行い、この時IOは準備ができておらず、待機状態の集合に入る.IO準備が整い,コパス運転を開始し,その後sleep操作を行い,このとき睡眠状態集合に入る.待機(wait)セットはどのようなデータ構造で格納されますか? 準備完了(ready)セットには優先度を設定するオプションはありません.すべての作業優先度が一致するので、準備完了の作業を格納するためにキューを使用できます.略称は準備完了キュー(ready_queue)です.  睡眠(sleep)集合は睡眠時に成長する順に並べ替えられ、赤黒樹を用いて記憶される必要があり、略称睡眠樹(sleep_tree)赤黒樹は工程的に実用的であり、keyは睡眠時間が長く、valueは対応する協程結点である.待ち受け(wait)集合は、IOの準備が整うのを待つ機能であり、IOを待つのも長い場合があるため、待ち受け(wait)集合は赤黒樹を用いて格納され、待ち受け木(wait_tree)と略称される.ここではnginxの設計を参考にする.
      データ構造を下図に示す.
      Coroutineはコヒーレンスの対応する属性であり、statusはコヒーレンスの実行状態を表す.sleepとwaitの2つの赤と黒の木、readyが使用するキュー、例えばある協程呼び出しsleep関数、睡眠木(sleep_tree)、status|=Sを加えるとよい.例えば、あるスレッドが待機ツリー(wait_tree)にあり、IOがreadyキューに入れる準備ができている場合は、待機ツリー(wait_tree)を移動し、ステータスをstatus&=~Wに変更すればよい.実行ステータスのコヒーレンスにかかわらず、準備キューに含まれているが、他の実行ステータスが同時に含まれているという前提条件があります.
    7.2スケジューラと連携の機能限界
    各コパスで使用する必要があり、異なるプロパティがある可能性があります.コパスプロパティです.各コヒーレンスに必要でデータが一致するのが、スケジューラのプロパティです.たとえば、スタックサイズの数値では、各コヒーレンスが同じになった後に変更を行わずにスケジューラのプロパティとして使用でき、各コヒーレンスサイズが一致しない場合は、コヒーレンスのプロパティとして使用できます.  は、スケジューラのプロパティとしてすべてのコヒーレントなプロパティを管理するために使用されます.たとえばepollは,各コヒーレントに対応するIOを管理するために用いられ,スケジューラ属性として必要である.
      前述の章の説明に従って、1つのコモン構造体がどれだけのドメインを必要とするかを定義し、各コモンには独自のコンテキスト環境があり、CPUのレジスタctxを保存する必要があるかを説明した.サブプロシージャのコールバック関数funcが必要です.サブプロシージャコールバック関数のパラメータargが必要です.自分のスタック空間stackを定義する必要があります.自分のスタックスペースが必要なサイズstack_size;コラボレーションの作成時間birthを定義する必要があります.現在の運転状態statusを定義する必要があります.現在の運転状態のノード(ready_next,wait_node,sleep_node)を決定する必要がある.コヒーレンスidを定義する必要があります.スケジューラのグローバルオブジェクトschedを定義する必要があります. 協程のコア構造体は以下の通りである.
    typedef struct _nty_coroutine {
    
        nty_cpu_ctx ctx;
        proc_coroutine func;
        void *arg;
        size_t stack_size;
    
        nty_coroutine_status status;
        nty_schedule *sched;
    
        uint64_t birth;
        uint64_t id;
    
        void *stack;
    
        RB_ENTRY(_nty_coroutine) sleep_node;
        RB_ENTRY(_nty_coroutine) wait_node;
    
        TAILQ_ENTRY(_nty_coroutine) ready_next;
        TAILQ_ENTRY(_nty_coroutine) defer_next;
    
    } nty_coroutine;
    

      スケジューラは、すべての協程実行を管理するコンポーネントであり、協程とスケジューラの実行関係である.
      スケジューラの属性は,CPUを格納するレジスタコンテキストctxが必要であり,コパス運転状態yieldからスケジューラ運転まで可能である.コプロセッサからスケジューラ用yield、スケジューラからコプロセッサ用resume.
      以下は協程の定義である.
    typedef struct _nty_coroutine_queue nty_coroutine_queue;
    
    typedef struct _nty_coroutine_rbtree_sleep nty_coroutine_rbtree_sleep;
    typedef struct _nty_coroutine_rbtree_wait nty_coroutine_rbtree_wait;
    
    typedef struct _nty_schedule {
        uint64_t birth;
    nty_cpu_ctx ctx;
    
        struct _nty_coroutine *curr_thread;
        int page_size;
    
        int poller_fd;
        int eventfd;
        struct epoll_event eventlist[NTY_CO_MAX_EVENTS];
        int nevents;
    
        int num_new_events;
    
        nty_coroutine_queue ready;
        nty_coroutine_rbtree_sleep sleeping;
        nty_coroutine_rbtree_wait waiting;
    
    } nty_schedule;
    

    より多くの共有
    email: [email protected] email: [email protected] email: [email protected]技術交流グループ:829348971