I am splitting an application in two, and therefore replacing some C++ function calls by gRPC calls. The new modules can run on different machines or on the same one (even in the same process). Do I need a mechanism (e.g. mutex/locking) to avoid multithreading issues, which where not present before?
As I understand, the gRPC server uses thread-pools and may handle each request on a different thread. That basically opens up potential for multithreading issues. However, my client code is single-threaded, so the second (gRPC) call is executed only after the first (gRPC) call has returned. I am unsure whether this guarantees that ALL side-effects of the first call are visible to the second call, and everything still works as if it was run on a single thread. So far, the application seems to work fine without any locks, but that might just be "luck", as it often is the case with threading issues...
The only related question I found is Order of function calls -gRPC, but that question does not specify how the client code is invoking the calls. And it also seems the poster can actually reproduce an issue, while my application seems to work fine so far