Skip to content
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

[BBT#565] Implement the BRAVO biased reader/writer lock #324

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

devreal
Copy link
Contributor

@devreal devreal commented Mar 2, 2022

The goal of the BRAVO biased rwlock is to avoid readers taking the reader lock and thus contending for the atomic variable. Instead, readers raise a flag in an array to signal that they "took the lock" to any future writer. A writer takes the underlying atomic lock and waits for all readers to complete. While a writer has the lock, readers wait for the atomic rwlock.

The hash table in PaRSEC is a prime example for a use-case: writers are extremely rare since the resizing happens rarely and the max size is capped. However, every thread locking a bucket also takes a reader-lock. We can thus avoid the contention on the global lock for most of the application run.

The original proposal used a global hash table for all locks (https://arxiv.org/abs/1810.01553) but we use one array per lock. We know the number of threads in PaRSEC and can use fixed offsets, with padding to prevent cache line sharing (64B per thread). If an unknown thread takes the lock it goes straight to the atomic rwlock (unfortuntely, this includes the MPI progress thread at the moment).

This is still WIP, needs more testing and evaluation.

Open question:

  • Does the comm thread not have an execution context? If so, can we access the global context in another way to know the number of threads in PaRSEC during initialization?

Original PR on Bitbucket: https://bitbucket.org/icldistcomp/parsec/pull-requests/565

Signed-off-by: Joseph Schuchart schuchart@icl.utk.edu

@devreal devreal added the enhancement New feature or request label Mar 2, 2022
@devreal devreal self-assigned this Mar 2, 2022
@devreal devreal requested a review from bosilca as a code owner March 2, 2022 14:40
@devreal devreal marked this pull request as draft March 2, 2022 14:40
@devreal devreal changed the title Implement the BRAVO biased reader/writer lock [BBT#565] Implement the BRAVO biased reader/writer lock Mar 2, 2022
The goal of the BRAVO biased rwlock is to avoid readers taking the reader
lock and thus contending for the atomic variable. Instead, readers raise a
flag in an array to signal that they "took the lock" to any future writer.
A writer takes the underlying atomic lock and waits for all readers to
complete. While a writer has the lock, readers wait for the atomic rwlock.

The hash table in PaRSEC is a prime example for a use-case: writers are
extremely rare since the resizing happens rarely and the max size is capped.
However, every thread locking a bucket also takes a reader-lock.
We can thus avoid the contention on the global lock for most of the
application run.

The original proposal used a global hash table for all locks
(https://arxiv.org/abs/1810.01553) but we use one array per lock.
We know the number of threads in PaRSEC and can use fixed offsets, with
padding to prevent cache line sharing (64B per thread). If an unknown
thread takes the lock it goes straight to the atomic rwlock (unfortuntely,
this includes the MPI progress thread at the moment).

Signed-off-by: Joseph Schuchart <schuchart@icl.utk.edu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant