Why does CSP use a synchronous execution model?

[MrMonad]

I have been studying the CSP documentation and was wondering about the design motivations for the execution model.

Many engines like Flink, Heron etc rely on an asynchronous execution model and use watermarks to mark barriers for synchronization. CSP uses a synchronous model instead.

[AdamGlustein]

Can you elaborate on what you mean by "asynchronous" execution? Are you referring to the fact that the csp engine is single-threaded?

[MrMonad]

Yes I'm wondering why it's single threaded for the entire graph.

Flink for example will assign a portion of the graph to execute on a single thread, but threads communicate asynchronously. SABER is more fine grained and will break a single graph node to many small tasks that are serviced by a thread pool. Hazelcast Jet is similar to flink but uses cooperative scheduling. CSP more coarse grained and assigns the entire graph to a single thread (except maybe the adapters?).

[AdamGlustein]

Parallel or distributed csp still remains a topic of discussion and an area for future growth.

The primary reason that the engine runs on a single-thread is GIL constraints. Since users can write pure Python nodes which will invoke the GIL, multithreading node execution gets hairy. Rank-level parallelization (what you are suggesting, passing nodes off into a thread pool) will only work to our advantage if all node are using a C++ implementation.

A secondary reason is that even with the C++ nodes, many are very quick computations, so the overhead of maintaining the thread pool/synchronization is more than the node itself. For example, baselib nodes like sample, merge etc. are all extremely simple and do not warrant running in a thread outside the engine.

Assigning "portions" of the graph into separate processes could be possible but it would require some sophisticated algorithms to decide how to divide the graph up. Also, managing multiple Python interpreters in separate processes does not sound too fun. However, parallel csp is still up for discussion, and I'd be interested to hear ideas on how we could execute it. Note that we have the function csp.run_on_thread available if you want to run multiple different graphs in separate threads.

[AdamGlustein]

Also, Flink uses watermarks to handle out-of-order events, since per their docs:

"When it comes to supporting event time, Flink’s streaming runtime builds on the pessimistic assumption that events may come out-of-order, i.e. an event with timestamp t may come after an event with timestamp t+1."

Since csp keeps its own internal engine time which is never out-of-order, we don't have this issue.

[MrMonad]

If I understood the differences correctly, the CSP adapters are supposed to resolve inconsistent timings by ordering the data before it enters the graph. Flink decides to order the data within the graph instead, and so they need these markers to help reorder the stream.

[AdamGlustein]

Yes, but since csp has a single engine thread with a single engine time, the data will always be well-ordered.