4 ms·

I skimmed the linked technical paper until I got the implementation details. It's a tree of integers. This is similar to my thoughts of a latch grid, which is b

I skimmed the linked technical paper until I got the implementation details. It's a tree of integers. This is similar to my thoughts of a latch grid, which is basically an increment and if statement against a grid to see what is ready. I was imagining a programming language that has "latches" or "barriers" as a primitive of the language. Barriers and CountdownLatches are just If statements if a number is equal I think. But I want barriers or latches that can schedule "something else" if the barrier is not ready. How many times have you been deep in the depths of some code and realised you need to wait for something in another part of the system to become true? I think lifecycles and state machines and barriers and latches are related, so I'm trying to define a syntax that looks like this: substate1(a) substate2(b) = substate3(a) substate4(a) | substate5(b) substate6(b) When substate1 and substate2 are "fired", the state machines waits for substate3 and substate4, then when they fire it waits for substate5 and substate6. I can either rely on barriers or latches or rely on explicit scheduling to implement this state machine. EDIT: It occurred to me that Go's channels and CSP and its send/receive operations are like barriers.

rkangel 3y ago
FWIW, that line you've written looks a lot like Verilog (or any other hardware description language).
adrian_b 3y ago
You can have barriers that can schedule "something else" if the barrier is not ready, by using the services provided by the operating system. For instance, in Linux you can use the syscalls FUTEX_WAIT and FUTEX_WAKE. Instead of waiting in a loop for the barrier variable to reach the right value, invoking FUTEX_WAIT will schedule "something else". Whoever modifies the value of the barrier variable invokes FUTEX_WAKE, so that everybody who waits will check if the new value is what they are waiting for, otherwise they will yield execution again. In Windows there is the analogous function WaitOnAddress(). Without using the operating system, on Intel or AMD CPUs it is possible to use the instructions MONITOR and MWAIT, or their unprivileged variants UMONITOR and UMWAIT (the latter are available only in some recent models). By invoking MWAIT/UMWAIT, a thread will sleep until another thread will execute a store instruction towards the monitored barrier variable, changing its value.

rkangel 3y ago

FWIW, that line you've written looks a lot like Verilog (or any other hardware description language).

adrian_b 3y ago

You can have barriers that can schedule "something else" if the barrier is not ready, by using the services provided by the operating system. For instance, in Linux you can use the syscalls FUTEX_WAIT and FUTEX_WAKE. Instead of waiting in a loop for the barrier variable to reach the right value, invoking FUTEX_WAIT will schedule "something else". Whoever modifies the value of the barrier variable invokes FUTEX_WAKE, so that everybody who waits will check if the new value is what they are waiting for, otherwise they will yield execution again. In Windows there is the analogous function WaitOnAddress(). Without using the operating system, on Intel or AMD CPUs it is possible to use the instructions MONITOR and MWAIT, or their unprivileged variants UMONITOR and UMWAIT (the latter are available only in some recent models). By invoking MWAIT/UMWAIT, a thread will sleep until another thread will execute a store instruction towards the monitored barrier variable, changing its value.