Are QueryMethod's synchronized with WorkflowMethods and SignalMethods? If so, why?

I know that workflows use cooperative multithreading and guarantee that only one of the SignalMethods or the WorkflowMethod is running at once. Does that also extend to the QueryMethods? For instance, if my workflow is processing a large number of signals, will the QueryMethod be effectively blocked until it gets its turn or is the QueryMethod not included in that single-threaded synchronization?

I understand why you’d want to synchronize the query and workflow methods because they can both modify shared state, but because the query method is not intended to modify state, it seems that it could be excluded from the synchronization.

1 Like

So I’m adding Max here as he will have a much more robust answer but… I believe they are “ordered” (synchronized might not be the right word) and that we guarantee strong consistency when querying after a signal is sent (read after write). Im not sure this has anything to do with cooperative multithreading.

I know that workflows use cooperative multithreading and guarantee that only one of the SignalMethod s or the WorkflowMethod is running at once.

It is a little bit more nuanced. Only one thread can run at a time due to cooperative multithreading. But if a signal method blocks (for example on Workflow.sleep) the thread yields the control to some other thread and another signal can be delivered to the same method. I filed an issue to make this behavior configurable.

I don’t think processing a large number of signals should be a problem for a query method. The question is what processing means in your context. If processing is nonblocking and just updates some shared data structures (like buffering signals in a queue) then it is really fast and the query will execute after the signals are processed. If processing is blocking then the query is not going to wait for the signal methods completion and is going to execute as soon as all signal processing threads are blocked.