1

私は共有メモリとプロセス間通信の基本を知っていますが、私のアプリケーションはかなり具体的であるため、一般的なフィードバックを求めてこの質問をしています。

私は、32ビットのビジュアルコーディングツールキットを使用して、64ビットマシン（MacOSおよびWin 64）で作業しています。現時点では、ツールキットを64ビットに移植することは実用的ではないため、メモリに制限があります。

私は、高品質のビデオを高速でスクラブ（ユーザー入力に基づいて前後に移動）できる必要があるアプリケーションに取り組んでいます。明らかな解決策は次のとおりです。1-すべてをメモリに保持します。2-ディスクからのストリーム。現時点ですべてをメモリに入れるには、ビデオ品質を許容できないレベルまで下げる必要があり、ディスクからストリーミングすると、ロード中にスクラブがハングします。

私の現在の考え方は、マスタープログラムと複数のスレーブプログラムを実行することです。各スレーブはビデオのセグメントをRAMにロードし、マスタープログラムがビデオの異なるセクションをロードする必要がある場合、スレーブにこのデータを要求して転送します。

私の質問は、これを行うための適切な方法は何ですか？共有メモリでは、アプリケーションが現在持っている32ビットメモリの制限を乗り越えることができないと思います。パイプのような簡単なこともできましたが、もっと適したものは他にあるのではないかと思いました。

理想的には、このソリューションはMac / Winポータブルですが、最終的なソリューションはWindowsボックスに存在する必要があるため、Windowsソリューションを選択します。また、これに開発時間で何週間も費やすつもりはないので、簡単であるほど良いです。

よろしくお願いします。

4

2 に答える 2

2

すべてのコードを64ビットに移植することは現実的ではありませんが、64ビットOSで64ビットマシンを使用している（または少なくとも使用できる）と推測します。また、気になるデータを保持するのに十分なメモリがマシンにあると想定しています。本当の問題は、32ビットコードからそのメモリに十分にアクセスできることです。

その場合は、やなどのWindowsのアドレスウィンドウ化拡張（AWE）関数を調べAllocateUserPhysicalPagesますMapUserPhysicalPages。これらはファイルマッピングと非常によく似ていますが、データをアドレススペースにマップするときに、ディスクから読み取る必要がなく、すでに物理メモリにある点が異なります（つまり、マッピングがはるかに高速です）。

于 2012-12-15T16:26:18.903 に答える
1

配布の要件に応じて、 Memcachedの1つ以上のインスタンスを埋め込みまたはインストールし、ディスクからmemcacheへの1つ（または必要に応じて）のスレッドフィードブロックを用意します。

データをmemcachedに移動すると、特にmemcached自体が64ビットプロセスとして実行される場合は、32ビットの制限の影響をほとんど受けません。

基本的に、プログラムではファイルではなくソケットから読み取り、memcachedは豪華なファイルキャッシュになります。

于 2012-12-15T15:58:25.883 に答える