1

条件変数の待機操作を実装しています。条件変数の構造体があります。これまでのところ、私の構造体にはモニター、キュー、およびスピンロックがあります。しかし、条件変数がそれ自体でキューを持つべきかどうかはわかりません。私の通知は次のようになります：

 void uthread_cv_notify (uthread_cv_t* cv) {
     uthread_t* waiter_thread;
     spinlock_lock(&cv->spinlock);
     waiter_thread   = dequeue (&cv->waiter_queue);
     if(waiter_thread)
     {
        uthread_monitor_exit(cv->mon);
        uthread_stop(TS_BLOCKED);
        uthread_monitor_enter(cv->mon);
        spinlock_unlock(&cv->spinlock);
     }
}

しかし、通知機能と待機機能のどちらで、モニターの待機キューにエンキューおよびデキューする必要があるのでしょうか。

ありがとう

4

2 に答える 2

0

シグナル操作（notifyと呼んでいる）では、モニターに入る必要はありません。これは非効率的です。

「通知」の呼び出し元がモニター内にいる必要がある、不器用な昔ながらの状態/モニターシステムを実装しようとしているようです。スレッドが待機している場合、そのスレッドは「通知」の発信者はモニターに戻ります。（そして、その待機中のスレッドは、条件を再テストするループを持つ必要もありません。）

これは、CAR Hoareが最初にモニターと条件を説明した方法かもしれませんが、形式主義は、最新のマルチプロセッサーシステム、および低レベルスケジューラーと非常に緊密に統合されるという贅沢を持たないスレッド実装では非現実的/非効率的です（どのスレッドがいつ実行されるかを正確に制御するため、誰が最初にミューテックスを取得するかについての競合はありません。たとえば、ある待機キューから別の待機キューにスレッドを転送できるようにするなどです）。

spinlock_lockモニターのクリティカルセクションを操作全体および操作全体に拡張する方法に注意してくださいdequeue。これらはどちらも監視下にありません。スピンロックは独立しており、キューはモニターではなくスピンロックによって保護されています。モニターは、ユーザーコードの共有変数（待機操作の特別なアトミックプロパティ）のみを保護する必要があります。

于 2012-03-29T03:08:33.723 に答える
0

では、なぜ追加のキューが必要なのですか？通知が必要なすべてのスレッドをすでに保存しています。

また、おそらく次のようなことをしたいと思うでしょう。

void uthread_cv_notify（uthread_cv_t * cv）{
     uthread_t * waiter_thread;
     spinlock_lock（＆cv-> spinlock）;
     waiter_thread =デキュー（＆cv-> waiter_queue）;
     if（waiter_thread）
     {{
        uthread_monitor_exit（cv-> mon）;
        uthread_stop（TS_BLOCKED）;
        uthread_monitor_enter（cv-> mon）;
     }
     spinlock_unlock（＆cv-> spinlock）;
}

これにより、スピンロックが常に解除されます。

于 2012-03-28T20:01:32.110 に答える