Add test case to return zero on a closed channel #8167
Conversation
|
@kavyasrinet I am not sure why we need this. @chengduoZH has already implemented a PR where the send and receive return a boolean. If channel got closed, we get a boolean false and if the send/receive was successful we get a true. I don't think this test is needed. We have already added tests for checking the boolean. This was done to keep the implementation similar to Go Channels and was also suggested by @wangkuiyi. This is how Go implements this -> https://golang.org/ref/spec#Receive_operator. As long as we provide the boolean, the channel does not need to give any guarantees on the read value. It is the responsibility of the thread that is calling receive to see what boolean was returned. it should use the value in the pointer only if |
|
I agree with your comment above that closing a channel will return the boolean In addition to the point above, once the reviewers agree on the behavior as mentioned in the unit test, I can go ahead and change the CloseChannel implementation as well to perform the mentioned behavior. |
paddle/framework/channel_test.cc
Outdated
| @@ -60,6 +60,32 @@ TEST(Channel, SufficientBufferSizeDoesntBlock) { | |||
| delete ch; | |||
| } | |||
|
|
|||
| // This test tests that CloseChannel returns a value of zero | |||
| // immediately to all receivers that are trying to receive from the channel. | |||
| TEST(Channel, ReceiverGetsZeroOnClosedChannel) { | |||
There was a problem hiding this comment.
If the purpose of this PR is to add a unit test to ensure that
- receiving from a closed buffered channel returns residual values and then zeros values, and
- receiving from a closed unbuffered channel doesn't block and returns zero.
then this PR looks too simple to ensure the above two invariants.
There was a problem hiding this comment.
I think one of the axioms was that : A receive from a closed channel returns the residual values and then zeros.
This PR tries to validate that #1 you explained above holds since we aren't explicitly checking for the zero value anywhere else.
paddle/framework/channel_test.cc
Outdated
| // immediately to all receivers that are trying to receive from the channel. | ||
| TEST(Channel, ReceiverGetsZeroOnClosedChannel) { | ||
| const size_t buffer_size = 10; | ||
| auto ch = MakeChannel<size_t>(buffer_size); |
There was a problem hiding this comment.
This invariant should be verified with buffered and unbuffered channels.
There was a problem hiding this comment.
On a side note, correct me if I am wrong @wangkuiyi but for an unbuffered channel, since the buffer size is zero, there would be no residual values. So trying to read from a closed channel should just return a zero value, right ?
paddle/framework/channel_test.cc
Outdated
| EXPECT_EQ(ch->Send(&i), true); // sending should not block | ||
| } | ||
|
|
||
| CloseChannel(ch); |
There was a problem hiding this comment.
Maybe receive some values before CloseChannel and checks that receivings after CloseChannel return the residual values.
There was a problem hiding this comment.
Thank you for pointing that out! Will fix it in a commit.
|
#8175 This is for your reference. @kavyasrinet |
|
Thank you! |
paddle/framework/channel_test.cc
Outdated
| int out; | ||
| for (size_t i = 1; i <= 12; ++i) { | ||
|
|
||
| for (size_t i = 6; i <= 12; ++i) { |
There was a problem hiding this comment.
Both 6 and 12 are magical numbers.
|
Thank you, will do. |
|
Closing this, since #8175 fixes the same issue. |
This test case covers the expected behavior of receiving in a closed channel as explained in the Axioms here : https://github.com/PaddlePaddle/Paddle/blob/2500f30ef210e8e55cccb5cc18ab525941e970f2/doc/design/csp.md