5

共有 POSIX ミューテックスがすでに初期化されていると仮定します (PTHREAD_PROCESS_SHARED を使用)。

次に、次の手順を検討します。

typedef struct {
    pthread_mutex_t mutex;
    // ...
} Shared;

Shared *shared = (Shared *)mmap(...); // MAP

pthread_mutex_lock(&shared->mutex); // LOCK

// REMAP
munmap(shared, ...);
shared = (Shared *)mmap(...);

pthread_mutex_unlock(&shared->mutex); // UNLOCK

POSIXは、これが「単純に」意図したとおりに機能することを保証していますか?

私が見る限り、関連するマニュアルページのどれもそのようなシナリオに言及していません.

また、次の Linux 固有の代替案はどうでしょうか。

Shared *shared = (Shared *)mmap(...); // MAP

pthread_mutex_lock(&shared->mutex); // LOCK

shared = (Shared *)mremap(shared, ...); // MREMAP_MAYMOVE

pthread_mutex_unlock(&shared->mutex); // UNLOCK

たとえば、プロセス内のどこかにロックされたミューテックスへのポインターを格納する PTHREADS 実装を想像できます。ミューテックスが堅牢 (PTHREAD_MUTEX_ROBUST) として構成されている場合、ミューテックスがロックされている間にプロセスが停止した場合、実装はミューテックスを「放棄」としてマークできます。

そのようなスキームが実際に機能するかどうか、POSIX で許可されているかどうか、またはミューテックスの堅牢性がどのプラットフォームで実際にどのように実装されているかはわかりませんが、これらの線に沿った実装が機能し、POSIX に従って有効である場合、上記の再マッピング シナリオでは、未定義の動作が発生します。

4

1 に答える 1

2

いいえ！

@Celada が指摘したように、Linux での堅牢なミューテックスの実装では、ロックされた堅牢なミューテックスが固定アドレスに留まっていると想定しています。

http://www.kernel.org/doc/Documentation/robust-futexes.txt

このことから、ロックされたミューテックスの再マッピングを禁止する実装が POSIX で許可されていることはある程度確信を持って結論付けることができます。そうしないと、Linux の実装が正しくなくなります。

したがって、質問で概説した手順は正しくないと見なされ、未定義の動作につながるはずです。

于 2013-02-27T20:54:16.077 に答える