2011-06-07 11 views
1

私は、ワーカースレッドで実行するようにスケジュールされたタイマーベースのアニメーションプログラムを持っています。このプログラムは、起動時に常に動作するように設計されています。また、画像処理を担当する画像作成スレッドを持っていて、各処理画像(JPEG/PNG形式)をアニメーションスレッドに送り、ユーザーの介入なしに画像ループに参加します。

これは一般的なメモリベースのイメージループプログラムです。つまり、ユーザが選択したすべての画像がRAMにロードされています。私はマップコンテナを使用して、データ型のCBitmapポインタでKey型のイメージファイル名を関連付けるstd :: mapの形式で宣言されたイメージシーケンスを管理します。また、イメージファイルリストのコピーを上記のマップキーリストに対応するソートされた順番で保持するために、vecter文字列(std :: vectorのように宣言されている)を使用して、各イメージを順番に繰り返します。それは必要ではないかもしれません。 animaion制御に関しては

、以下のキオスクのような操作が許可されている(いくつかは、彼らのrespectve変数の宣言を伴う):m_dwTo変数が使用して、ユーザーが変更することができ
C++のマルチスレッドスレッドセーフアニメーションの提案

bool m_bPlay; // Play forward 
bool m_bPause; // Pause animation 
bool m_bStop; // Stop animation 
bool m_bReverse; // Play backward 
bool m_bRepeat; // Repeated play when reaching to last image 
DWORD m_dwFrom; // Starting image number 
DWORD m_dwTo; // Ending image number 
DWORD m_dwCurrent; // Current image number 
DWORD m_dwFPS; // Frames per second 


主GUIウィンドウの上部に表示されたツールバーに埋め込まれたスピンボタンの、または新たに処理された画像が上記のマップおよびベクトルコンテナに追加されるたびにアプリケーションによって自動的に増加される。同様に、m_dwFrom変数は、m_dwToと同じ方法で手動で変更することも、ユーザー定義のローリングアーカイブ設定に基づいて1つ以上の再生中の画像が期限切れになるたびにアプリケーションによって自動的に減らすこともできます(たとえば、keep 3日後の画像)、同時に、上記のマップおよびベクトルコンテナから期限切れの画像を削除する必要があります。 m_dwFPS変数は、メインGUIウィンドウの上部に表示されたツールバーに埋め込まれたドロップダウンリストボックスを使用して、イメージルーピングの過程でいつでも変更することができます。

私がしたいと思っている長い説明を読んでいただきありがとうございます。私はそれが私の次の質問に答える中であなたを助けることができることを願っています:

  1. m_dwFrom、m_dwTo、m_dwCurrent、およびm_dwFPSスレッドを安全にするために、それはより効率的かつ性能よりInterlockedExchangeやInterlockedCompareExchangeを使用することによって獲得されますCriticalSection、Mutexなどの他のロックの使用?
  2. std :: mapとstd :: vector threadを安全にする方法はありますか?従来のロックのみを使用するか、コンパイラの並べ替え障壁(たとえば、Visual C++の_ReadWriteBarrier)やCPUリオーダリングバリア(たとえば、MemoryBarrier x86およびx64 CPUファミリ)と併用するのがよいでしょうか?

ご意見をお待ちしております。コードまたは誤ったコードスニペットが高く評価されます。前もって感謝します!

ゴールデン・リー

+0

申し訳ありませんが、私は2番目の質問を繰り返します:2。どのようにstd :: map とstd :: vector をスレッドセーフにするか?従来のロックのみを使用するか、コンパイラの並べ替え障壁(たとえば、Visual C++の_ReadWriteBarrier)やCPUリオーダリングバリア(たとえば、MemoryBarrier x86およびx64 CPUファミリ)と併用するのがよいでしょうか?

答えて

0

私は間違っているかもしれないが、私の知る限り、あなたの説明から推測できるように私はあなたの共有ベクトルを作成し、あなたの他の共有変数はスレッドセーフとしてaswellマッピングするために、伝統的なロックとミューテックスで行くと思います。これは単に最も簡単な方法であり、あなたのシナリオは、より複雑な何かを正当化するためにそのパフォーマンスを集中的に訴えません。プロファイリングで伝統的なロックがパフォーマンス上の問題になることがわかったら、私は何かに触れたいだけです!

std :: mapとstd :: vector threadを安全にする方法はありますか?

これを行う一般的な方法は、アクセスが必要なコンテナ関数の周りにロックラッパーを書き込むことです。例えば:例えばブースト::スレッドを使用した場合、標準のロックプリミティブでの滞在について

class myAnimationManager{ 
private: 
std::map<std::string, CBitmap*> m_imagesMap; 
Mutex m_mutex; 

public: 
CBitmap * getImageByName(const std::string & _name) 
{ 
ScopedLock l(m_mutex); //lock image map access 
return m_imagesMaps[_name]; 
} 
//... 
}; 

の良いところは、シンプルさだけでなく、移植だけではありません。

+0

Q2に返信いただきありがとうございます。私は昨年、簡単なアニメーションプロジェクトを終えました。しかし、それは7X24の1年間の実行のために数回墜落した。私のアニメーションレポジトリのstd :: map は、アプリケーションを停止させる最も疑わしいオブジェクトです。それで、それが私の第二の質問の主な目的です。ところで、私はCriticalSectionを使用して、アニメーションフレームの読み書き競合状態を防ぎました。 –