5

リーダーライターロックを実装しました

 typedef boost::unique_lock<boost::shared_mutex> WriterLock;
 typedef boost::shared_lock<boost::shared_mutex> ReadersLock;

ここには、多くのマルチスレッドリーダーと少数のライターしかありません。リーダーは他のリーダーとアクセスを共有しますが、ライターをブロックします。ライターは、リソースへの排他的アクセスができるまでブロックします。

ブーストドキュメントでこれを見つけることができませんでした...ライターの飢餓を防ぐためのポリシーは何ですか？
たとえば、すべてのリーダーがスレッドプールからロックをドキドキしている場合、ライターが最終的にロックを取得するまでのロック試行回数に上限はありますか？

リーダーがまったくなくなるまで書き込みを待機する必要があることを示しているように見えるパフォーマンスの数値が見られます。現在のリーダーのサービス中に新しいリーダーがロックを要求できるため、それが長い時間になることはまれです。その場合、私たちのコードでは、ライターは読み取りがまったくなくなるまで非常に長い時間を待たなければならないようです。

ライターがロックを要求すると、現在のすべてのリーダーが排出されますが、すべての新しい着信リーダーがライター要求の背後でブロックされる、よりキューのようなシステムをお勧めします。

Boostのアップグレード可能なロックの概念の動作は何ですか？ ブーストスレッド

それは、作家の飢餓をどのように処理するかについてはどちらの方法でも述べていません。

4

3 に答える 3

1

複数のリーダーと複数のライターの公平性を高める @Guerrero のソリューションの小さな改善により、誰も餓死することはありません。

read() {
    while (atomic-write-requests > 0)
        condition.wait();
    ReadersLock lock(acquireReaderLock());
    doRead();
}
write() {
    while (atomic-write-requests > 0)
        condition.wait();
    atomic-write-requests++;
    WritersLock lock(acquireWriterLock());

    doWrite();
    atomic-write-requests--;
    condition.notify();
}

このソリューションでは、ライターがスコープを離れるたびに、新しく公正な競争が始まります。

于 2015-11-17T09:02:07.667 に答える
0

必要なのがFIFOアプローチである場合、boostはステートチャートライブラリにいくつかのスケジューリング戦略（FIFOを含む）を実装します。ただし、これを使用するには、多くのコードを適応させる必要があると思います。fifo_schedulerおよびFifoWorkerに関するドキュメントを確認してください。

http://www.boost.org/doc/libs/1_51_0/libs/statechart/doc/reference.html#FifoWorker

http://www.boost.org/doc/libs/1_51_0/libs/statechart/doc/reference.html#fifo_scheduler.hpp

于 2012-10-25T20:45:13.023 に答える
0

ブーストの実装についてよく知らなくても、実装によってライターの枯渇を防ぐことができるかもしれません。ライターが存在する間、リーダーは待機できます。たぶん、この擬似コードのように： 

read() {
    while (atomic-write-requests > 0) {
        condition.wait();
    }
    ReadersLock lock(acquireReaderLock());
    doRead();
}
write() {
    atomic-write-requests++;
    WritersLock lock(acquireWriterLock());

    doWrite();
    atomic-write-requests--;
    condition.notify();
}
于 2012-10-25T20:35:10.323 に答える