-
Notifications
You must be signed in to change notification settings - Fork 154
Tutorial for shared memory access (RefPorts) #99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just some minor comments. If you address these, you can just get the sign offs from people in your time zone tomorrow.
- "on a Loihi Neurocore from" -> NeuroCore
- "The read/write of RefPorts are still implemented via messages and can be used across compute resources." Check my tutorial00. Be sure to elaborate a bit more on what this means. You have to say that we do not really access memory of other processes directly . We just expose it as such through the read/write API for convenience. We don't break with the CSP paradigm, thus even read/write is implemented via channels and message passing and the remote process modifies its memory itself based on instructions from another process.
- You could make your prints a little more interesting by printing out the current time steps in front of the value since this is anyways purely for demonstration purposes. Then it's clear to associate the prints with you explanation in the comment.
- Incorrect: "An implicit VarPort is created when connect_var(..) is used to connect a RefPort with a VarPort" An ImplicitVarPort is created when connected to a Var directly.
- The section on "Options to connect RefPorts and VarPorts" Could benefit from a figure showing a hierarchical process. Otherwise it's a bit hard to follow how and why when such cases would arise.
- Any reason for the big space between PyProcModel1 and 2?
- You could also simply demonstrate that RefPorts work the same way hierarchically by constructing a simple hierarchical process.
- In order to make this a deeper dive tutorial than what I'm covering in tutorial00, you could also showcase how RefPort/VarPort interaction relates to SET/GET commands from the Runtime level: You should show that RefPort access takes precedence by doing something with a Var both via SET/GET and RefPort to make the order explicit.
By the way, do RefPorts already support multiplicity like 1:many or many:1? If so? You could give an example. If not, be sure to raise exceptions in the Port objects if a user tries to do that if you have not done that already.
…Var or VarPorts/RefPorts - skipped a unit test: testing multiple connections
I addressed most of your remarks and added error messages if one tries to make a 1:many/many:1 connection. This is currently not supported and not a trivial change. Also, it seems that currently using RefPorts with hierarchical processes is not working, it does not read the correct value (have not tried writing yet). |
So why is that? There should not be any difference if hierarchical processes are involved since the hierarchy gets flattened out anyways. The first question would be does get_dst_ports() perhaps not work correctly across hierarchies? |
Fixed the issue, RefPorts and VarPorts work now also with hierarchical processes. |
…Var or VarPorts/RefPorts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine.
I just have a minor comment about style and a refactoring suggestion. But you can do this later. Does not have functional implications.
Don't want to hold this up any further.
Added a tutorial explaining the usage of RefPorts and VarPorts.