New Synchronisation Primitives - Replacement for CondVar and Condition

[jordan]

Responding to this from another thread, as that one was a question, which has been answered.

@jamshark70

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.)

@jamshark70

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?)

TLDR: Don’t use Barrier for this.

I have never found an instance where synchronising with routines and the server is more performant than just writing it synchronously and calling s.sync.
I am not too sure on how this is implemented — I’m have trouble locating the part of the library that handles this —, but as I understand, s.sync will be added to the server’s synchronous to do list, once all previous commands have been executed, the message is sent back to the language to continue. This means other sclang threads might have to wait for other thread’s buffer allocations to finish before it can. Therefore, it is pointless to call them asynchronously. I spent a lot of time with FluCoMa trying to eek out more performance this way… huge waste of time (the optimisation, not the library). Now perhaps something could be done by using completion messages (not too sure on that), but that isn’t something Barrier (or perhaps even any class/function) can address. One option (which I quite like) might be making a Buffer.readBlocking method that uses the action callback to unblock, wrapping all the details of that inside so for the user (and in the context of Barrier) the code appears synchronous. Better yet would be if Buffer.read just returned a Future that automatically decayed to a buffer if present, waited if in a routine, and throws an error if not.

Or, I think this could be a good use for a Channel, or even just using the action directly…

~bufChan = Channel();

Buffer.read(s, "..", action: ~bufChan.insert(_))

fork {
	var b = ~bufChan.extract();
    ... blah blah blah
}

If you have any counter examples, please let me know!

… or even better for this specific issue, a multiple buffer loader class, since this issue pops up so many times on this forum.

@jamshark70

provide a public method `release

The aim here is to make synchronisation methods that, if they don’t throw on error (hopefully an early error), they work. That isn’t always possible, but requiring the user to remember to do something seem contrary to this. Actually, what you are suggesting seems just like CondVar and the solution from the other thread, but with a slightly nicer syntax.