grpc/test/cpp/qps/server_async.cc

67 views
Skip to first unread message

Saroj Mahapatra

unread,
Nov 4, 2019, 6:47:40 PM11/4/19
to grpc.io
Hi,

Why does the TreadFunc locks and unlocks ‘ctx’ every time in the loop? How does the race condition arise?

Thanks.

Saroj Mahapatra

unread,
Nov 4, 2019, 6:55:00 PM11/4/19
to grpc.io
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.

Charlie Magnuson

unread,
Nov 6, 2019, 1:49:18 PM11/6/19
to grpc.io

Ctmahapa95

unread,
Nov 6, 2019, 7:24:02 PM11/6/19
to Charlie Magnuson, grpc.io
Yes. 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 grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/231aff4d-e43f-43ce-aa09-529713d23195%40googlegroups.com.

Vijay Pai

unread,
Nov 12, 2019, 1:21:48 AM11/12/19
to grpc.io
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 grp...@googlegroups.com.

Ctmahapa95

unread,
Nov 12, 2019, 7:01:12 AM11/12/19
to Vijay Pai, grpc.io
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.


To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/d12da475-05df-4ae0-90a9-03860e198f11%40googlegroups.com.

Vijay Pai

unread,
Nov 12, 2019, 12:09:34 PM11/12/19
to grpc.io
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

Ctmahapa95

unread,
Nov 28, 2019, 9:36:58 AM11/28/19
to Vijay Pai, grpc.io
Vijay, thank you for your detailed explanation. After the server shutdown, can no async operation (read/write/request/finish) be started or just no request can be registered?

Is it also required that CQ shutdown must happen after server shutdown?

Thank you.


To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/74cd9e77-089c-4ea3-99e2-b1bcd65a61ad%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages