Hacker News Reader

Comment by marcosdumay | Hacker News Reader

> "synchronize" literally has the word "time" in it as a greek root (χρόνο/chrónos).

Oh, yeah, the simple times before everybody learned that time is a local and observer-dependent measure.

Modern computers do almost none time-based at-distance synchronization. About 2 decades ago, when I was studying asynchronous computation, hacking the chip-design process to make it possible to do time-based synchronization of nearby transistors on the same silicon crystal was a very trendy idea. It was very hard, because everything is extremely noisy, and I imagine the idea faded away, because everything is much more noisy nowadays. Doing that on any large scale is asking for everything to break.

For all of the computer-era, synchronization has being done by signaling. The millenia-old tech of doing it by time is just deprecated.

View on HN

> Oh, yeah, the simple times before everybody learned that time is a local and observer-dependent measure. Modern computers do almost none time-based at-distance synchronization.

This is a very odd response. Nothing you write here directly contradicts the parent comment and yet you seem to imply that you have a point that is the opposite of the parent comment.

You seem to be going off on a tangent without addressing the main point that chips do depend on a clock firing periodically and that clock interval determining how long the circuitry waits for its pins to achieve a stable binary state before the next state transition. That was the original point of the parent comment and that point is still valid.

How does signaling work without time?

I'm having a really hard time understanding your question.

If it's on the line of "signals only exist because we have time", then yeah, duh; and it's such an outrageous misconstruction of my comment that I imagine you meant something else.

What do you mean by signaling? What happens under signaling?

With signaling, something locally determined tells when your synchronized nodes need to stop or go, and makes them do that by sending a message.

This is what happens when your connection library starts a call-back after it connects; or blocks until the connection is ready; or use some continuation scheme, like futures to reorder your program and only start the next line of code after the connection is ready.

The alternative is what the article does. AFAIK, you can only do it in Javascript, because it's so obviously bad that no other language supports it.

For my example in circuitry, signal based synchronization uses a clock, or a ready signal. Time based synchronization just uses circuits that are ready to read data exactly when the previous step is done calculating it.

> For my example in circuitry, signal based synchronization uses a clock, or a ready signal.

But clock is not a ready signal. The clock is just a periodical signal that keeps firing. If you squint your eyes, it is almost like an event loop performing a time.sleep(ns) before deciding to check the state. In the case of chips, the circuitry performs the next state transition after the very short delay decided by the periodical clock signal. The assumption that every pin would acquire a stable binary state before the next clock tick is a fundamental part of a chip design. Without that we'll have non-deterministic and ill-defined chip behavior.

A clock is not really a ready signal though. It is really a regularly cycling signal. It is not generated when a component is done with work, instead components are implemented on such a way to be guaranteed to be done in one clock cycle.

I don't think they understand their question either.

The question "How does signaling work without time?" makes complete sense to me. I understand this question. Do you not?

The question is actually a rhetoric implying that "signalling" in the chip level involves time, namely, the clock signal that is firing periodically. It is not so much as a signalling as it is like an assumption baked into the circuit design. The circuit must change its state from one state to another only at the next clock signal and not before that.

Well there you go. Physical events are not in fact limited to occurring at clock transitions. But even if they did, it still doesn't make any particular amount of time into a correct stand-in for a serial dependency. The passage of 150ms of time is not what makes thing B clear to proceed. The only thing I don't understand is how anyone can not understand that.

The point is that at the hardware level, arbitrary timings are in fact used. The same logic as

   usleep(100000);  // give other thread enough time to do B

is actually correct at the hardware level. Devices are expected to produce a stable output within some arbitrary time, that they meet. If they don't, a garbage value is blindly read anyway: there is no actual cause-and-effect synchronization other than adherence to the timing diagram's requirements.

That usleep is wrong. Sure they exist all over the place, but they are wrong. They are merely easy and "good enough". But other thread has not finished it's job because 100ms passed. Other thread does something. Whatever other thread does is the definition of done and ready, not usleep 100000. sleep is crossing your fingers and hoping that other thread did actually finish doing whatever it exists to do by then.

The fact that digital circuits operate by different parts all being synced to clock pulses, and some parts even count the pulses such that the 7th bit in a byte is actually picked out strictly by the timing of 7 pulses, is pointless pedantics when the article is operating in an entirely different domain which does not operate that way and there is cause & effect and the definition of a service being ready is when the service is ready, not any particular passage of time. The service might actually be ready before you even asked, or might still not be ready in an hour, or might have come up fully and gone back down all within the sleep.

Today the service takes 100ms to start and you have a 150ms sleep. Tomorrow the same service runs on faster hardware and takes 1ms to start, and now has it's own wrong timing assumption where when it starts, it shuts back down if there are no clients (stupid thing for most services to do, but people do stupid things all the time), it starts up and sleeps 50ms "to give time for the client". The 150ms sleeping client doesn't issue any requests, the service shuts back down.

You have to be writing the firmware to a spinning disk to talk about time being the actual definition of anything.

> Physical events are not in fact limited to occurring at clock transitions.

You seem to be talking about "events". We are not talking about events. We are talking about the clock component of CPU chips that keeps emitting a periodical signal.

> The passage of 150ms of time is not what makes thing B clear to proceed.

It absolutely does. Except that in modern chips the time interval is in nanoseconds. Two decades ago, it used to be in microseconds.

Not trying to be snarky but a genuine question: Do you have any background in chip design and fab? What @kazinator and I are saying is not exactly surprising. These things are taught in undergrad or grad-level integrated circuit courses.

If the circuitry didn't wait those nanoseconds before the next state change, it would be making the state change based on intermediate and possibly garbage values which would make the chip behave in a non-deterministic manner.

Again, we are not talking about events or cause-and-effect. We are talking about something that is more fundamental and is baked into the design of CPU chips at the very lowest level.

Reply on news.ycombinator.com