-
Notifications
You must be signed in to change notification settings - Fork 21
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
MPSC count can become negative #49
Labels
Comments
mratsim
added a commit
that referenced
this issue
Dec 15, 2019
mratsim
added a commit
that referenced
this issue
Dec 15, 2019
* Try to fix the "deadlock" in batch receive, somehow it's also 5% faster (to be checked in Travis, deadlock not reproduced locally) * Ignore nimble during runs nim-lang/nimble#696 * don't auto fail due to getTicks on ARM * Negative count is non-blocking, can be investigated later (#49) * When using C++ we need C++11 * typo * Make travis Arch visible * fix arch
Hopefully solved by partial model checking in #128 (memory bug on the model checker that interrupts it, ...) |
Still happening in the memory pool:
|
mratsim
added a commit
that referenced
this issue
May 16, 2020
mratsim
added a commit
that referenced
this issue
May 16, 2020
Merged
mratsim
added a commit
that referenced
this issue
May 16, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Even though the count is done on the consumer side which should always underestimate the real count, the number of estimated enqueued item in the MPSC channel can be negative.
See #48 (comment) and CI https://dev.azure.com/numforge/Weave/_build/results?buildId=25&view=logs
This is not blocking as this count is only informative and used for adaptative stealing and for the memory pool to trigger batch reception of memory.
This is something I actualy remarked in the past but seems to happen rarely:
weave/weave/channels/channels_mpsc_unbounded_batch.nim
Lines 208 to 220 in fffffd1
The text was updated successfully, but these errors were encountered: