Create select_op design document #9139
Conversation
…OP_DESIGN_DOC, fix some issues with select_op design doc
doc/design/csp/select_op.md
Outdated
| @@ -0,0 +1,94 @@ | |||
| # select_op Design | |||
There was a problem hiding this comment.
Commenting on the graphics here:
- In select_op.png, the
casesattributes does not make sense if you don't explicitly annotate what those comma-separated values represent - In Block0, some indication of the fact that there are other blocks before and after the select op
- The Block1 diagram is difficult to understand, even though you have all the right things in all the right places. Not that this fixes the problem, but the fill_contants being used with different values
0and1doesn't make much sense - it needs to be explicit about its use of index.
There was a problem hiding this comment.
In select_op_workflow: The "push queuemessage on all involved channels and block current thread" is a very loaded concept. Either this gets broken down here or in text or really well picked up and talked about in the channels doc.
For the line that says "execute sub_block", it would be much nicer if the previous diagram has a big bold name on that block, and you use the same name here. Or use colors. Or something that makes the connection between the two different places where the "sub block" is being talked about.
There was a problem hiding this comment.
I can change the select_op.png to just show the actual program desc. I'lll also update the text for push queuemessage
doc/design/csp/select_op.md
Outdated
|
|
||
| ## Introduction | ||
|
|
||
| In golang, the **select** statement lets a goroutine wait on multiple |
There was a problem hiding this comment.
Wouldn't hurt to have a link to the go tutorial page
doc/design/csp/select_op.md
Outdated
| ## Introduction | ||
|
|
||
| In golang, the **select** statement lets a goroutine wait on multiple | ||
| communication operations at the same time. The **select** blocks until |
There was a problem hiding this comment.
channel operations. Being agnostic here does not have much of a purpose here
There was a problem hiding this comment.
Select depends on channel operations, I think we should discuss it.
There was a problem hiding this comment.
Oh I meant "channel operations" rather than "communication operations"
doc/design/csp/select_op.md
Outdated
| With the introduction of CSP for Paddle, we mimic this behavior by | ||
| creating a ***select_op***. The ***select_op*** works in conjunction | ||
| with the **channel_send_op**, **channel_receive_op**, and | ||
| **channel_close_op**. |
There was a problem hiding this comment.
Umm is it? I thought select_op does not use the channel ops? Doesn't it just use Channels directly?
There was a problem hiding this comment.
That's true, I'll just say it works with ChannelHolder directly
doc/design/csp/select_op.md
Outdated
| will prefer to use the much simplier Python API. | ||
|
|
||
| - **fluid.Select()**: Creates a Select block and adds it to the main | ||
| program block. Within the select block, users can add cases by calling |
There was a problem hiding this comment.
Not main program block right? It will be in whichever block select_op sits in
There was a problem hiding this comment.
I'll change this to the current block within the main program
doc/design/csp/select_op.md
Outdated
| assign(input=x, output=x_tmp) | ||
| assign(input=y, output=x) | ||
| assign(elementwise_add(x=x_tmp, y=y), output=y) | ||
| with select.case(fluid.channel_recv, quit_channel, result2): |
doc/design/csp/select_op.md
Outdated
| while_cond = fill_constant(shape=[1], dtype=core.VarDesc.VarType.BOOL, value=True) | ||
| while_op = While(cond=while_cond) | ||
|
|
||
| with while_op.block(): |
There was a problem hiding this comment.
While is a little tricky case - not sure I would use it for an example introducing it for the first time. BUT if you want to use to show how it can work with while, you might have to add a little more text perhaps below the example to explain why we do that funky append_op business to get out of the while. Because there is nothing normal about it.
doc/design/csp/select_op.md
Outdated
|
|
||
| The python select API will add the **select_op** to the current block. In addition, it will | ||
| iterate through all it's case statements and add any input variables required by case statements | ||
| into **X**. It will also create a temp variable called **case_to_execute**. This variable is |
There was a problem hiding this comment.
And make a note about the outputs also here, since we added that
There was a problem hiding this comment.
case_to_execute is not really a tmp variable. We are explicitly passing it in. So it will modify the variable case_to_execute
There was a problem hiding this comment.
We are doing it for the user when they call fluid.select() right?
There was a problem hiding this comment.
Yes, so may be I just don't know what tmp variables means, you know better
doc/design/csp/select_op.md
Outdated
|
|
||
| Cases are represented by a **conditional_block_op** whose's condition is set as the output of | ||
| equal(**case_to_execute**, **case_index**). Since each case index is unique in this sub-block, | ||
| only once case will be executed. |
There was a problem hiding this comment.
Love the explanation. Concise and very accurate!
doc/design/csp/select_op.md
Outdated
| </p> | ||
|
|
||
| The select algorithm is inspired by golang's select routine. Please refer to | ||
| http://www.tapirgames.com/blog/golang-concurrent-select-implementation for more information. |
There was a problem hiding this comment.
So I realize the hard way that Tapir Liu is not the best explainer in the world, and the reason we spent so much time understanding his blog was because he didn't do the best job of summarizing that code. Reading the code brought all the clarity.
Anyways, you don't need to do anything here, this is a just a comment/thought.
…OP_DESIGN_DOC # Conflicts: # doc/design/csp.md # doc/design/csp/csp.md # doc/fluid/design/concurrent/csp.md
No description provided.