Paper: Making Redstone Async

[Gaurav99]

Suggestion

Would it technically be possible to make redstone be processed on a separate thread? This would ideally be optional, as it would only really be useful for servers with heavy redstone usage like Skyblock & Creative.

I'm no expert, so I apologize if I sound kind of stupid here but essentially in my head, it would work like this: When a redstone element (redstone wire, diode, comparator, torch, etc.) gets activated by a player (whether that be through a lever, or a button, or whatever) -- that would be sent to the redstone thread (and all subsequent actions -- like a powered redstone wire powering the one next to it) would be done on that thread. If a redstone machine such as a piston is activated, it would call synchronized() or however you would put it on the main thread, and activate the piston.

Again, since the repeated switch between threads may be CPU-intensive, it would only make sense for certain servers (hence why it would be optional). And, while it may be difficult to implement and would probably take some time, it would be extremely beneficial to Skyblock & Creative servers, or just any server that has intense redstone use. Instead of limiting redstone or stopping players from creating redstone clocks entirely (like a lot of servers have done), they could just make it process off the main thread with this option and keep their servers running lag-free while not having to restrict what players can do.

Thanks in advance,
Gaurav

[aikar]

While not pure async, sponge is working on a change that we are likely to do as well once figured out, that moves block ticking to be done async in parallel per world.

I may be wrong on that exact description, but you can not make redstone truly async, only parallel, without breaking game expectations.

[AlfieC]

@aikar: could something similar to your TaskChain be used? Would simplify the "weaving" between async and sync operations.

[Techcable]

Modifying the physics loop to be iterative instead of recursive could also help, and without breaking much either.
The JIT favors iterative code, as do most traditional optimizations.

[Spottedleaf]

Redstone would be a nightmare to do this for.

User created structures -> Redstone can affect (i.e TNT) and/or may be affected by many blocks (other redstone (implicitly covered below)), thus limiting options for concurrency. Acquiring a lock for each block? Acquiring a lock for a general area ( crossing chunk borders would be painful here)? Other solutions?

Assuming that synchronization is taken care of (for sake of argument), what happens between the task being sent to the redstone thread and the task being executed? No assumptions can be made that no state has changed between this time frame (and if you bar state from changing, what's the point in going async?). So the state has to be re-evaluated entirely once the task is executed on the redstone thread. What about redstone ticking becoming de-synchronized with the regular server tick?

How would running redstone tasks async affect server plugins?

What about command blocks? With command blocks, redstone ticking may execute commands asynchronously. Commands such as setblock can not be executed in such a manner, so you would have to enforce synchronous execution with command blocks and redstone ticking. (what if the command block modifies state which is relied upon in a redstone configuration?)

Finally, how would this feature enforce state visibility between the main thread and the redstone thread?

Drop the romantic attitude with threading. It is not a _design_ without downsides and neither is it guaranteed increase performance.

[Techcable]

Async is definitely not a good idea, and making it parallel would be too much work, and difficult to maintain

[aikar]

Yeah I don't think we'll be able to do this.... It's too risky and touches too much of the server code to ever be able to safely do it.

Gonna close. If someone wants to go ham and try it, open a PR, but I don't think any of the Paper core team can justify working this.