UNIX で semop() 関数を使用すると、sem_op =0 の sembuf 構造体を提供できます。基本的に、これは呼び出しプロセスがセマフォの値がゼロになるまで待機/ブロックすることを意味します。Windowsでこれを達成する同等の方法はありますか?
私が実装しようとしている特定の使用例は、ライターに書き込みを許可する前に、リーダーの数がゼロになるまで待機することです。(はい、これはセマフォを使用するやや非正統的な方法です。これは、リーダーの数に制限がなく、セマフォが通常管理するために使用される一連の制約されたリソースがないためです)
unix semop システム コールに関するドキュメントは、http: //codeidol.com/unix/advanced-programming-in-unix/Interprocess-Communication/-15.8.-Semaphores/にあります。
Windows セマフォは、最大値 (許可されるリーダーの最大数) からゼロまでカウントダウンします。WaitXxx関数はゼロ以外のセマフォ値を待機してデクリメントし、セマフォをインクリメントします (セマフォで待機している他のスレッドがブロックを解除できるようにします)。別の方法で Windows セマフォを待機することはできないため、Windows セマフォはおそらく同期プリミティブの間違った選択です。Vista/2008 では、スリムな読み書きロックを使用できます。以前のバージョンの Windows をサポートする必要がある場合は、自分で作成する必要があります。ReleaseSemaphore
私が実装しようとしている特定の使用例は、ライターに書き込みを許可する前に、リーダーの数がゼロになるまで待機することです。
ライターがすべて完了するまで、リーダーの数がゼロのままであることを保証できますか?
その場合、最後のリーダーの完了を通知する手動リセット イベント オブジェクトを使用して、SysV の「ゼロ待ち」動作と同等のものを実装できます。SetEvent()「アクティブなリーダー」の独自の（同期された）カウントを維持し、リーダーが終了するにつれて減少し、そのカウントがゼロになったときに、辛抱強く待っているライターに信号を送ります。
リーダーの行儀がよいことを保証できない場合は、SysV sem を処理する場合でも不幸な競争が発生します。
Win32 API に似た関数は見たことがありません。
方法としては、セマフォ作成時に指定した最大回数と同じ回数を呼び出すWaitForSingleObjectなどして取得することだと思います。WAIT_OBJECT_0次に、利用可能なすべての「スロット」を保持し、セマフォで待機している他の人はブロックします。