Make the number of "camera scans" constant in the philosophers benchmark #447
Conversation
This file contains 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
Reduces visibility of some elements, uses named fork objects, moves status formatting to the "image" capturing method, and adds white space around separate logical steps.
Take a snapshot of the state within a transaction and then format it (outside the transaction) to avoid blocking the mutators. This is what actual state monitoring code should be doing.
Camera scans are requested based on thread progress. To keep the number of camera scans constant, the requests are queued to avoid potential loss of wake-ups when the rate of progress increases (due to reduced contention towards the end of the workload). This is a proof-of-concept, it would be nice to replace the LinkedBlockingQueue with an STM-based solution.
Uses simple counters instead to ensure that we always perform a fixed number of scans for a given workload and that the camera thread terminates when the number of scans reached the expected total.
Also adds a `block_meal_count` parameter which determines the number of meals that represents a block of progress. The size of the block determines the number of camera scans, which the benchmark validates.
lbulej
force-pushed
the
topic/philosophers-const-scan
branch
from
169cbe3
to
05ad765
Compare
|
Rebased to master and updated the commit ids in the description. |
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.
This includes two related changes and one extra bit.
The first reduces the duration of the transaction building the "image of the scene". Previously the image was being built inside the transaction, making the transaction last unnecessarily longer. Now we only take a snapshot of the state within the transaction and build the image outside the transaction to avoid blocking philosopher threads.
The second change makes the number of scans constant for a given workload. Previously, camera scans were triggered in reference to wall clock time, resulting in variable number of scans during each repetition. Now the camera scans are requested based on thread progress. To keep the number of camera scans constant, the requests are counted to avoid potential loss of wake-ups when the rate of progress increases (due to reduced contention towards the end of the workload).
These two changes should alleviate the banding in the operation durations (#202), but probably not entirely, because there simply is a thread that periodically blocks all threads for a while.
The extra bit is inclusion of the number of camera scans in the validation.
Below are plots from simple measurements I collected from 15 runs (150 repetitions each) using JDK 11 (default settings) on 8 cores of Xeon E5-2697A v4:
split_scanvariant corresponds to commit d3a614aconst_scan_lbqvariant corresponds to commit 18b4936 (scan requests queued usingLinkedBlockingQueue)const_scan_stmvariant corresponds to commit 05ad765 (scan requests "queued" using STM transactions)