There's a requirement that new RPCs can't be registered once the server has been shutdown nor can new RPC operations be initiated once the CQ has been shutdown. These are, imo, the two rough edges in the C++ CQ-based async API. The shutdown mutex protects against that possibility. Note that it's actually an array of mutexes: one per RPC-processing thread. So, in the common case, the mutex will be uncontended since the same thread keeps accessing it over and over again. Only at shutdown the master thread will take the locks on each of the worker threads and shut them down, after which they'll next see their shutdown state updated and will stop performing operations. Because it's uncontended in the common case, it's unlikely to cause any substantial positive performance impact if it is removed, and its removal will require some alternative mechanism of enforcing the shutdown contract described above.
- Vijay On Tuesday, November 12, 2019 at 4:01:12 AM UTC-8, Ctmahapa95 wrote: > > Thanks for the explanation. In the same vein, is there any reason to use a > shutdown mutex instead of calling server shutdown and then cq shutdown? > With these two mutex removed, probably the c++ benchmark program will show > marked improvement? > > Thank you. > > > On Nov 12, 2019 at 6:21 AM, <'Vijay Pai' via grpc.io <javascript:>> wrote: > > Hi there, > > I think I'm the original writer of that locked code. It's about a new CQ > tag posting for the same RPC while a call to RunNextState is still > outstanding (which could happen in particular if the operation initiated by > RunNextState completes quickly). It's true that having 1:1 thread:CQ would > not allow this since the CQ would not be polled until after the existing > call to RunNextState completed. I hope that helps and feel free to reach > out with any follow-ups. > > - Vijay > > On Wednesday, November 6, 2019 at 4:24:02 PM UTC-8, Ctmahapa95 wrote: >> >> Yes. Thank you. >> >> >> On Nov 6, 2019 at 1:49 PM, <'Charlie Magnuson' via grpc.io> wrote: >> >> Hello Saroj, >> >> Are you referring to this loop? >> https://github.com/grpc/grpc/blob/15c67e255b30c407aafcafe72d91bbaaad7a49dd/test/cpp/qps/server_async.cc#L220 >> >> On Monday, November 4, 2019 at 3:55:00 PM UTC-8, Saroj Mahapatra wrote: >>> >>> My guess is that if multiple threads are using the same ‘cq’, then two >>> threads might run the ‘RunNexrState’ function at the same time. Is that >>> correct? Does the need for ‘ctx’ licking go away with one thread per ‘cq’? >>> >>> Thank you. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "grpc.io" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/grpc-io/231aff4d-e43f-43ce-aa09-529713d23195%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/231aff4d-e43f-43ce-aa09-529713d23195%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/d12da475-05df-4ae0-90a9-03860e198f11%40googlegroups.com > > <https://groups.google.com/d/msgid/grpc-io/d12da475-05df-4ae0-90a9-03860e198f11%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/74cd9e77-089c-4ea3-99e2-b1bcd65a61ad%40googlegroups.com.
