Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Complete thread-safety #7

Open
1 of 3 tasks
nelsonxb opened this issue Jan 29, 2020 · 3 comments
Open
1 of 3 tasks

Complete thread-safety #7

nelsonxb opened this issue Jan 29, 2020 · 3 comments
Labels
category:enhancement New feature or request priority:needed This is needed for a major use case

Comments

@nelsonxb
Copy link
Owner

nelsonxb commented Jan 29, 2020 •
edited
Loading

While multiple threads can have their own coroutines, this is not documented, and an individual coroutine is not safe for thread migration.

  • Make thread activation/deactivation atomic;
  • Document this behaviour;
  • Find some way to deal with thread-locals.
@nelsonxb nelsonxb added category:documentation Improvements or additions to documentation category:enhancement New feature or request priority:wanted This would be nice to have at some point labels Jan 29, 2020
@nelsonxb
Copy link
Owner Author

Thread-locals will probably be dealt with by documenting their caveats (and discouraging their use).

@nelsonxb nelsonxb added priority:needed This is needed for a major use case and removed category:documentation Improvements or additions to documentation priority:wanted This would be nice to have at some point labels Jan 29, 2020
nelsonxb added a commit that referenced this issue Jan 31, 2020
@nelsonxb
Add (theoretical) thread-safety to x86_64 (#7)
ef82e72 
The current implementation passes existing tests, and while I'm pretty
sure it'll be thread-safe, I don't yet know how to test this. As there
is room for doubt, I am not yet documenting this behaviour.

This was started as an effort to clean away the unnecessary activate and
deactivate utility functions (in favour of calling _green_current
directly). Sort of got out of hand; I wasn't expecting to implement this
quite so early.

Since there are no tests for this, other architectures/platforms likely
won't mimic this capability right away.
@nelsonxb
Copy link
Owner Author

This has been implemented early for x86_64, however there are not yet tests guaranteeing this. As such, new platforms may be considered acceptable without mimicking this behaviour.

To clarify, the general strategy here is to guarantee that a coroutine can't be resumed twice. The only thing that is changing here is guaranteeing that this cannot happen in a multi-threading context. The only thing that's really needed to assert this, is to make the process of activating a coroutine atomic. Since (due to the atomic activation) it is guaranteed that an await will only ever occur on a single thread at a time for a given coroutine, all that green_await() needs to do is make sure it's finished operating within the coroutine before it gets marked as deactivated.

@nelsonxb
Copy link
Owner Author

nelsonxb commented Feb 1, 2020

Same thing should be implemented in AArch64, too. Again, hard to test this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
category:enhancement New feature or request priority:needed This is needed for a major use case
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@nelsonxb