grpc c++ async server example, is a mutex needed in the processing state?

Question

The grpc c++ example has the following comment.

// Spawn a new CallData instance to serve new clients while we process
// the one for this CallData. 

I'm a bit confused by the sentence as it seems to suggest the new CallData instance can potentially serve a different client simultaneously. (Is it an event loop?)

However I don't see any new threads being created in the example. Am I correct to assume that no new threads are created and any shared variables that CallData might act on, does not need a mutex? Or is a mutex necessary?

For example if the code in the example was changed to the below, would I need a mutex?

...
else if (status_ == PROCESS) {
        // Spawn a new CallData instance to serve new clients while we process
        // the one for this CallData. The instance will deallocate itself as
        // part of its FINISH state.
        new CallData(service_, cq_);

        // Do I need a mutex here?
        // mutex.lock()
        service->do_something_to_variable();
        // mutex.unlock()

        std::string prefix("Hello ");
        reply_.set_message(prefix + request_.name());

Answer 1

I'll try to answer each of your questions.

I'm a bit confused by the sentence as it seems to suggest the new CallData >instance can potentially serve a different client simultaneously. (Is it an event >loop?)

The event loop here is the loop over cq_->Next() in HandleRpcs(). Creating a new CallData begins the process for serving another client (you can see in its constructor that it calls service_->RequestSayHello, which enables the system to process another incoming RPC). As soon as this is called, events concerning the new incoming rpc are added to the completion queue. If the previous rpc has yet to finish, events for that rpc will be added to the completion queue. This means we're using the new CallData to handle the new rpc simultaneous to using the old CallData to handle the previous rpc.

Am I correct to assume that no new threads are created and any shared variables that CallData might act on, does not need a mutex? Or is a mutex necessary?

Right, so there are no new threads being created in this example. The only thread that's acting is the one running HandleRpcs(). So when I talk about "simultaneous" in the answer above, this is referring to multiple ongoing rpcs at any time (each with their own CallData), but the processing isn't actually concurrent because there's only one thread in the example application. Now if there were multiple threads in the picture, a mutex to protect CallData's state could be a good idea (depending on whether there could be shared access to the state).

For example if the code in the example was changed to the below, would I need a mutex?

If what you have written was the only change to the code, no, you wouldn't need a mutex (and I'm not sure what method you're trying to call on service_ anyway).