アシュメムにはどのような特別な力がありますか？
誰かがashmemが作成された理由を説明できますか？
現在、mm/ashmem.cを閲覧しています。私が知る限り、カーネルはashmemをmmapできるファイルバックアップメモリと考えています。しかし、なぜashmemを実装するのに苦労するのでしょうか。 RAM fsをマウントし、filemap/mmapを使用してメモリを共有することで同じ機能を実現できるようです。
Ashmemはもっと凝ったことをすることができると確信しています-コードを見ると、ページの固定/固定解除と関係があるようです？
Ashmemを使用すると、祖先によって関連付けられていないプロセスが、名前でメモリマップを共有でき、自動的にクリーンアップされます。
昔ながらの匿名のmmapとSystemV共有メモリには、これらの要件のいくつかが欠けています。
System Vの共有メモリセグメントは、実行中のプログラムによって参照されなくなったときに固執します（これは、機能である場合もあれば、厄介な場合もあります）。
匿名の共有mmapは、親プロセスから子プロセスに渡すことができます。これは、そのように関連していないプロセスがメモリを共有する必要がある場合があるため、柔軟性がありません。
誰かがashmemが作成された理由を説明できますか？
David Turner（Android NDK）の常連）がこれに答えました なぜbionic/libc/include/sys/shm.hが削除されたのですか？ ：
...カップケーキのSystemVIPCは削除されました。詳細については、bionic/libc/docs /SYSV-IPC.TXTを参照してください。
簡単に言うと、System V IPCは設計上リークがあり、他のプロセスのためのスペースを空けるためにプロセスを強制終了することがごく普通で非常に一般的であるAndroidのランタイム環境ではうまく機能しません。最終的な結果として、これらのIPCに依存するコードは、カーネルのSysV IPCキーの内部テーブルをいっぱいにする可能性があります。これは、再起動によってのみ安全に解決できます。
将来的には、同じ問題が発生しない代替メカニズムを提供したいと考えています。現在提供しているものの1つは、この種の問題を回避するためにAndroid用に特別に設計されたashmemです（ただし、十分に文書化されていません）。セマフォにも同様のものが必要です。および/またはメッセージキュー。