Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
Florian Fischer
emper
Commits
2ab1777a
Commit
2ab1777a
authored
Apr 23, 2022
by
Florian Schmaus
Browse files
Merge branch 'inc-sleep-sem-threshold' into 'master'
increase the sleep semaphore threshold See merge request
!377
parents
fca60937
c54a6bd4
Changes
1
Hide whitespace changes
Inline
Side-by-side
emper/sleep_strategy/SemaphoreWorkerSleepStrategy.hpp
View file @
2ab1777a
...
...
@@ -133,32 +133,37 @@ class AbstractSemaphoreWorkerSleepStrategy
template
<
CallerEnvironment
callerEnvironment
>
[[
nodiscard
]]
inline
auto
mustNotify
()
->
bool
{
typename
Sem
::
CounterType
skipWakeupThreshold
;
if
constexpr
(
callerEnvironment
==
CallerEnvironment
::
ANYWHERE
)
{
// 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.
// TODO: Could it be >= workerCount ?
skipWakeupThreshold
=
workerCount
;
}
else
{
// For work from within emper we 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
// going to sleep.
// Note that sem_getvalue() is allowed to return 0 if there are
// waiting workers, hence we need to set the threshold also 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,
// then the skipWakeupThreshold value should be
// reviewed and potentially changed to '-1'.
skipWakeupThreshold
=
0
;
}
/* 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.
* This is sound because wakeupSleepingWorkers() is called from a active
* 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 guarantying
* progress but it is harmfull 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 unnessesary atomic
* operations on global state. This overhead was not measured in contrast to
* the harm caused to latency by beeing greedy when using the semaphore.
* Note that sem_getvalue() is allowed to return 0 if there are
* waiting workers, hence we need to set the threshold atleast 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,
* then the skipWakeupThreshold value could be
* reviewed and potentially changed to '-1'.
* skipWakeupThreshold = 0;
*/
const
typename
Sem
::
CounterType
skipWakeupThreshold
=
workerCount
;
auto
semValue
=
wakeupSem
.
getValue
();
return
!
(
semValue
>
skipWakeupThreshold
)
;
return
semValue
<=
skipWakeupThreshold
;
}
public:
...
...
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment