このイベントの実装を同期する最良の方法は

Question

ここではC++イベントを実装しようとしています。

class Event{ 
    typedef std::tr1::function<void(int&)> CallbackFunction; 
    std::list<CallbackFunction> m_handlers; 

    template<class M> 
    void AddHandler(M& thisPtr, void typename (M::*callback)(int&)) 
    {   
     CallbackFunction bound = std::tr1::bind(callback, &thisPtr, _1); 
     m_handlers.push_back(bound); 
    } 

    void operator()(int& eventArg) 
    { 
     iterate over list... 
     (*iter)(eventArg); 

    }} 

ここでのトラブルはスレッドセーフです。 AddHandlerとoperator()が同時に呼び出されると、事態が壊れる可能性があります。

これを同期するにはどのような方法が最適ですか？ミューテックスを使用するとパフォーマンスが低下する可能性があります。この場合、boost :: signalsやC＃eventのシーンで何が起こるのだろうか。

Answer 1

mutexは間違いなくあなたが探しているものです。各イベントに独自のミューテックスがある場合は、パフォーマンスについてあまり心配する必要はありません。その理由は、イベントを処理している間に多くのハンドラを追加しない限り、ミューテックスが競合することはまずありません。

しかし、同じオブジェクトに対してoperator（）メソッドを呼び出す複数のスレッドがある場合、このmutex はとなる可能性があります。しかし、それがなければ、どうやってスレッドセーフな方法でコールバックを確実に呼び出すことができますか？ （整数参照を渡してvoidを返すことに気がつくので、これらは再入可能ハンドラではないと仮定しています）

EDIT：あなたのコメントで非常に良い質問。正直言って、私は決してミューテックスが同期的な方法で使用されるときにオーバーヘッドが多くあったかどうかにはほとんど考えなかった。だから私はこの小さなテストをまとめました。

 

#include <stdio.h> 
#include <pthread.h> 

#define USE_PTHREAD_MUTEX 1 

int main(int argc, char * argv[]) { 

pthread_mutex_t mutex; 
pthread_mutex_init(&mutex, NULL); 

long useless_number = 0; 
long counter; 

    for(counter = 0; counter < 100000000; counter++) { 
    #if USE_PTHREAD_MUTEX 
    pthread_mutex_lock(&mutex); 
    #endif 
    useless_number += rand(); 

    #if USE_PTHREAD_MUTEX 
    pthread_mutex_unlock(&mutex); 
    #endif 
    } 

    printf("%ld\n", useless_number); 

} 
 

私のシステムでこれを実行し、以下のランタイムを取得しました。

USE_PTHREAD_MUTEX 0の場合、平均ランタイムは1.2秒です。

USE_PTHREAD_MUTEX 1では、平均実行時間は2.8秒です。

あなたの質問に答えるために、間違いなくオーバーヘッドがあります。あなたのマイレージは異なる場合があります。さらに、リソースへのアクセスのために複数のスレッドが競合している場合、必然的にブロックするために多くの時間が費やされます。また、純粋に同期的なコンテキストでは、mutexのロック/ロック解除を待つよりも、共有リソースへのアクセスに費やす時間が長くなる可能性があります。言い換えれば、ミューテックスロジック自体のオーバーヘッドは、おそらくこれらのものと比較して重要ではないでしょう。

Answer 2

まず、実装の可能性が不十分であると判断する前に、実際にどのようなパフォーマンス要件が必要かを判断する必要があります。これらのイベントを毎秒何千回も引き起こしていますか？あなたがいれば、実際にハンドラコンテナにハンドラを追加する必要が本当にありますか？

両方の質問に対する回答が何らかの理由で実際に「はい」の場合、ロックフリーのコンテナを調査する必要があります。これは、stlリストを使用できるのではなく、独自のコンテナを構築することを意味します。ロックフリーのコンテナは、リストの末尾がNULLかそれ以外の場合に原子的に決定するために、原子組み込み関数（たとえばWindowsのInterlockedCompareExchangeなど）を使用します。彼らは実際に同様の組み込み関数を使って実際にリストに追加します。複数のスレッドがハンドラを同時に追加しようとすると、さらに複雑になります。

しかし、マルチコアマシンと命令の再順序付けなどの世界では、これらのアプローチは危険に満ちている可能性があります。私は個人的に、あなたが記述したものと似ていないイベントシステムを使用しています。クリティカルセクション（これは少なくともウィンドウでは効率的です）で使用し、パフォーマンスの問題は発生しません。しかし、一方では、イベントシステムを介して送信されるものは約20Hz以上のものはありません。

パフォーマンス関連の質問と同様に、回答は常に別の質問に対する回答に基づいています。正確にどこであなたのパフォーマンスが必要ですか？

Answer 3

リストが本当にあなたのクラスなら、その性質上、アクセスするたびにロックする必要はありません。ミューテックスをロックしてリストの最後に投稿し、最後に到達したと思うときはロックします。

クラス内のハンドラの数をカウントする必要があります。反復処理を開始しようとしているときに、この数値に達するまで、ロックせずに喜んで反復することができます。

ハンドラを削除しようとすると、スレッド競合の問題が増えます。