0

In POSIX and Windows API have barriers that allow synchronizing n threads. When n threads waiting for the barrier they may proceed doing some work.

What I want is for threads to wait for a set of barriers. When any of the barriers have n threads waiting it unlocks, returning which one of the barriers that was unlocked. Looking at POSIX and Windows API this is not a part of the native API. Is there another way around it?

Target language is C/C++ but language agnostic solutions are also appreciated.

Bakground: I´m looking into CSP, the basis of Occam and an inspiration source for Go. I believe a runtime can treat Events as barriers. However that would require some way of waiting for multiple barriers. I´d like to getting around this without major effort put in a supervisor.


Edit: Making an example in CSP notation.

P = c -> c -> d -> P;
Q = d -> e -> Q;
R = c -> R | d -> SKIP;
RUNTIME = P || Q || R;

For those of you unfamiliar with the syntax, P is a process (thread) interacting with event c, then c again, then d, then works like P. Q works similar. R is defined as c then R or d then SKIP. RUNTIME is the concurrent process made from P, Q and R.

Events are synchronized similar to barriers; all processes must be able to deal with it at the same time for it to happen. The trick is that a process may be able to participate in a set of event such as R which may participate in c or d, but unable to because of other processes (P and Q) not being able to participate.

This is where the "wait for ANY from a SET of barriers" comes in. R may wait for c or d simultaneously, and depending on which one is unlocked will behave differently.

4

0 回答 0