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.

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

Measure (and handle) starvation issues with CAS loops #12

Open
martong opened this issue Feb 16, 2016 · 2 comments
Open

Measure (and handle) starvation issues with CAS loops #12

martong opened this issue Feb 16, 2016 · 2 comments

Comments

@martong
Copy link
Owner

martong commented Feb 16, 2016

From http://preshing.com/20150402/you-can-do-any-kind-of-atomic-read-modify-write-operation/

Suppose thread A has to do a bunch of extra work in the "modify" step for some reason, such that one of threads B, C, ... has almost always gotten in and updated the variable by the time A gets to the CAS call. Then A might have to retry many, many times before it succeeds.

...
Preshing:

I'm pretty sure individual threads could be made to starve indefinitely.

@martong
Copy link
Owner Author

martong commented Feb 17, 2016

About handling:
Once the starvation is detected then a lock (lightweight mutex) could be locked by the starving thread to ensure exclusive access to the shared variable.
This might not work, because

  • that lock would enforce stricter ordering rules than we had without it
  • we would have starvation on the lock

@martong
Copy link
Owner Author

martong commented Feb 17, 2016

How to detect starvation?
Count the iterations of the CAS loop.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant