Introduce Start/IsEmpty/WaitEmpty/Stop() methods for TaskScheduler
#44
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The idea previously was that a worker thread can't leave the scheduler role until the scheduler is stopped or there are tasks to do. But actually nothing prevents from leaving the scheduler, entering it again, and then sleeping on waiting for tasks. It allows to simplify the state machine of the scheduler a bit. Gives a guarantee that the scheduler-role will consume the front signal only once per scheduling iteration. This guarantee in turn is going to be quite handy in the future potential API improvement for making it possible to run the scheduler in user's threads. Part of #40
Atomic "and" + "or" are going to be quite handy in the next commits. They could be implemented manually, but it is much easier to just take the STL version. Needed for #40
Gerold103
force-pushed
the
run-method-3-interruptible-mutex
branch
7 times, most recently
from
9d62641 to
86145f3
Compare
The new class is a special type of mutex which allows to take the lock, go to sleep on some arbitrary condition (a condition variable, a epoll_wait() call, a Signal.ReceiveBlocking(), or something similar), and then get woken up when other threads want to take the ownership. This is an abstraction of the TaskScheduler's usecase. The scheduler workers are going to be taking the lock and sleeping when have to wait for new tasks or for a deadline. And other threads would forcefully take the ownership when need to do some maintenance work like stop/start of the scheduler or getting something out of the scheduler-role context. Currently there isn't much of the second type of work, but this will change in scope of #40. Part of #40
It replaces the previously used atomic flag and does basically the same at this point. But in the future the lock's usage is going to be extended to do more stuff in the scheduler. Part of #40
Those methods repeat the ones from IOCore. It is the next step towards allowing the user to run the scheduler in user-threads. Part of #40
The socket closure consists of 2 steps:
- Set the close guard. If wasn't already set, the set CLOSING
state.
- When see CLOSING state, ensure the close-guard is set and do the
closure.
The close guard and CLOSING state were both set using the relaxed
memory order.
It could lead to races on ARM. One thread could set close-guard
and then CLOSING state. Another thread could see the CLOSING
state, but not see the close-guard being set yet.
Lets fix that by making those threads sync on the state (similar
to how signals work in TaskScheduler). The first thread would
release-write. And the second thread would acquire-read. Then the
close-guard is properly synced between them.
Closes #46
Gerold103
force-pushed
the
run-method-3-interruptible-mutex
branch
from
86145f3 to
3c2a04f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #40.