One issue is that Condition (in its original version) couldn’t handle timeouts. It looked like it could, but thread timing was borked if the condition was signaled successfully. I proposed a fix for this, but it was decided that this was structurally inadequate and CondVar was added in place of that fix. The specific reasons for this, I don’t recall but they’re still all in the github issue/PR history.
Edit: One good reason to have put CondVar in place is that a structurally sound condition variable would be a better foundation for futures etc than Condition… but that development effort didn’t happen, at least not in the main library. So we just started using it directly.
In any case, thread sync is a bit of a rough edge. Since many SC users aren’t computer scientists, I think it would be helpful if we could decide on one general purpose approach and document it in a guide or tutorial. The nuances of futures vs channels vs the-next-fancy-thing-that-will-be-forgotten-two-years-later may be unnecessary complication.
Jordan’s Barrier reads nicely! But I have a bit of feedback… One of the main thread sync cases in SC is waiting for buffers to read from disk, which requires an explicit signal (rather than an implicit signal from reaching the end of a routine’s function)… s.sync pushes the sync job off to the server, and is probably adequate most of the time (why would one use Barrier for this when s.sync is easier?) but it raises the thought that there may be other sync jobs that need explicit signaling per sub-thread. If the only lock-release mechanism in Barrier is to exit the function, then this function needs to know when to signal, which just moves the sync problem to another part of the code. It might be a good idea to keep an IdentitySet of threads, and provide a public method release { |thread| set.remove(thread); condVar.signalAll } and the predicate would be { set.isEmpty }. (A countdown doesn’t account for a user accidentally releasing the same thread twice – they shouldn’t, of course, but you have no way to detect that case without keeping a collection.) The usage style looks very convenient – maybe this adjustment would cover more cases.
hjh