Nagarei

ごめんなさい。僕は「クラス内のstatic変数としてmutexを使う」ことにしても、この問題を解決する方法を思いつきません。 上のケースを解決するサンプルコードを書いていただけないでしょうか？

DrawnOn関数を仮実装ですが追加しておきました。

そのやり方だと、以下が反例になります。Run関数が呼んでいるLoadGraphScreenの書き込む先がDrawnOnのSetDrawScreenの呼び出しの前か後かで変わってしまいます。 このケースは異なるオブジェクトに対するアクセスなのでこのような曖昧さが生じるべきではないです。 ``` cpp void func() { Screen screen(640, 480); screen.DrawnOn([]{ DxLib::LoadGraphScreen( 0 , 0 , "test1.bmp" , TRUE ) ; }); } void Run(){ std::thread thd(); DxLib::LoadGraphScreen( 0 ,...

> 継承元のTexture2Dにmutex変数をstaticメンバー変数として持たせる DrawBox系をdxleに入れた場合問題になる、と思ったけれどそれはなさそうですね...。 しかし、将来こういう事が起こる可能性を考慮するとmutexをグローバル変数にしたほうが良いのではと思うのですがどう思いますか？

> mutexをstaticメンバー変数にもつクラスを例えばscreen_mutex_cとかいう名前で作って、それを継承したほうがいい気がしてきました・・・ ではそんな感じで作ってみます。

mutex系で一つのヘッダにするのと関連する機能のところに書くのとどっちが良いですかね？

WinAPIではmutexよりもクリティカルセクションを使った同期の方が早い模様。 https://msdn.microsoft.com/ja-jp/library/cc429052.aspx std::mutexは内部でどっちを使ってるんだろう...。 ただ、どうせDxLib関連の部分でマルチスレッドなんて誰も使わないので環境依存の少ないstd::mutexで実装します。

各クラスの説明のところにスレッドセーフ保障についてどのレベルで提供するかを書く事を提案します。 1. スレッドセーフ(DxLib関係なし) 2. C++11スレッドセーフ(DxLib関係なし) 3. スレッドセーフ(DxLibがスレッドセーフの場合) 4. C++11スレッドセーフ(DxLibがスレッドセーフの場合) 5. スレッドアンセーフ こんな感じでしょうか？ C++11スレッドセーフは[#4の僕の書き込み](https://github.com/Nagarei/DxLibEx/issues/4#issuecomment-153232270)の「全てが読み込み操作ならば排他制御は不要である」のことを指しています。

第二引数はDxLibの仕様のまま特に何もしなくても良いのではないでしょうか？

> mutexにアクセスできるようにしておけば十分な気がします。 それだとユーザーが「スレッドセーフを保証できなくなるDxLib側の関数」を完全に把握している必要が出てきます。すべてのユーザーがプロフェッショナルではないですし、こういう約束事はバグのもとになると思います。 > using namespaceした時に - DxLibの方にusing namespaceをdefineで無効化できるようにお願いする（さすがにわがままですかね？） - 接頭語としてdxleを付ける - using namespaceは禁止（仕様にする） というのを思いつきました。