Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
E
emper
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Terms and privacy
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Lehrstuhl für Informatik 4 (Systemsoftware)
manycore
emper
Commits
6921210c
Commit
6921210c
authored
2 years ago
by
Florian Schmaus
Browse files
Options
Downloads
Patches
Plain Diff
[SemaphoreWorkerSleepStrategy] Improve code comment
parent
3e01afe3
No related branches found
Branches containing commit
No related tags found
1 merge request
!385
[SemaphoreWorkerSleepStrategy] Improve code comment
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
emper/sleep_strategy/SemaphoreWorkerSleepStrategy.hpp
+12
-12
12 additions, 12 deletions
emper/sleep_strategy/SemaphoreWorkerSleepStrategy.hpp
with
12 additions
and
12 deletions
emper/sleep_strategy/SemaphoreWorkerSleepStrategy.hpp
+
12
−
12
View file @
6921210c
...
...
@@ -135,24 +135,24 @@ class AbstractSemaphoreWorkerSleepStrategy
[[
nodiscard
]]
inline
auto
mustNotify
()
->
bool
{
/* On external work we always increment the semaphore unless we observe
* that its value is > workerCount.
* If we observe semValue > workerCount we
are ensured
that some worker will iterate
* its dispatchLoop again and
must
observe the new work.
* For work from within
emper
we could skip wakeup if we observe no one sleeping.
* If we observe semValue > workerCount we
know
that some worker will iterate
* its dispatchLoop
()
again and
hence will
observe the new work.
*
* For work from within
EMPER,
we could skip wakeup
()
if we observe no one sleeping.
* This is sound because wakeupSleepingWorkers() is called from a active
* worker which will observe its own new work in its next dispatchLoop before
* worker which will observe its own new work in its next dispatchLoop
()
before
* going to sleep.
* BUT this supposed not harmful race may not be harmful for guarant
y
ing
* progress but it is harmful
l
for latency.
* BUT this supposed not harmful race may not be harmful for guarant
ee
ing
* progress but it is harmful for latency.
* Inserting new work in the system races with workers about to sleep
* actually able to execute the work in a timely manner.
* The overhead of increasing the semaphore "to" much are unne
sse
sary atomic
*
* The overhead of increasing the semaphore "to" much are unne
ces
sary atomic
* operations on global state. This overhead was not measured in contrast to
* the harm caused to latency by beeing parsimonious when using the semaphore.
* Note that sem_get
v
alue() is allowed to return 0 if there are
* waiting workers, hence we need to set the threshold atleast to
*
* Note that sem_get
V
alue() is allowed to return 0 if there are
* waiting workers, hence we need to set the threshold at
least to
* 0. This has the disadvantage that we will perform one
* unnecessary sem_post. If we are sure the wakeupSem
* implementation does not return 0 with waiters,
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment