私はオンラインで調べましたが、答えに満足することができませんでした。
memcpyはスレッドセーフですか?(Windowsの場合)
つまり、単一のmemcpyを使用して(boost :: shared_memory_objectを使用して)プロセス間で共有されるメモリ領域に書き込み、単一のmemcpyを使用して別のプロセスからその領域を読み取ろうとすると、その書き込み中に1つのプロセスが自動的にブロックされます。ハプニング?これについてどこで読むことができますか?
私はオンラインで調べましたが、答えに満足することができませんでした。
memcpyはスレッドセーフですか?(Windowsの場合)
つまり、単一のmemcpyを使用して(boost :: shared_memory_objectを使用して)プロセス間で共有されるメモリ領域に書き込み、単一のmemcpyを使用して別のプロセスからその領域を読み取ろうとすると、その書き込み中に1つのプロセスが自動的にブロックされます。ハプニング?これについてどこで読むことができますか?
memcpyは通常、生の速度でコード化されます。スレッドセーフではありません。これが必要な場合は、クリティカルセクション内でmemcpy呼び出しを実行するか、他のセマフォメカニズムを使用する必要があります。
take_mutex(&mutex);
memcpy(dst, src, count);
yield_mutex(&mutex);
memcpyはスレッド/プロセスセーフではありません
memcpy()(またはmemmove())のようなルーチンは標準Cライブラリの一部であり、標準の<string.h>ヘッダーに含まれており、ロックの仕組みについては何も知りません。ロックは、プロセス間ミューテックス、セマフォなどの外部的な方法で提供する必要があります。
「アトミック」と「スレッドセーフ」を混同しています。memcpy
共有リージョンでデータの読み取りと書き込み(の有無にかかわらず)を同時に行う場合、それは安全ではありません。しかしもちろん、データ自体のコピーはスレッドセーフです。
memcpy
それ自体もスレッドセーフです。少なくともPOSIXシステムではこれを参照してください。したがって、Windowsでも同様だと思います。他のものはそれを全く役に立たないものにするでしょう。
それが「自動的にブロック」される場合、それはアトミックである必要があり(または少なくともそれ自体のロックを管理する)、システムの速度を低下させます。したがって、あなたの場合、あなたはあなた自身のロックを使うべきです。