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

Thread Safety #650

Open
2 tasks
SSoelvsten opened this issue Apr 15, 2024 · 2 comments
Open
2 tasks

Thread Safety #650

SSoelvsten opened this issue Apr 15, 2024 · 2 comments
Labels
✨ feature New operation or other feature help wanted Extra attention is needed 🎓 student programmer Work, work... 🎓 student project Work, work... but academic!

Comments

@SSoelvsten
Copy link
Owner

SSoelvsten commented Apr 15, 2024

In many contexts, BDD packages should be threadsafe such that they can be used as part of parallel algorithms. It is not possible for such a program to know early how many threads may exist before it starts its calculations. Hence, Adiar has to adapt on-the-fly to the number of concurrent calls.

Luckily for us, the write-once/read-only design of Adiar's files makes thread-safety much easier (since we have no unique node table to lock). Yet, instead we have one global pool of M memory in TPIE that we are allowed to use. Hence, we need some kind of locking/scheduler to make sure every thread can claim a share of M "early". Otherwise, another thread can by accident overtake it and both ask TPIE for the same "free" memory.

  • Add ADIAR_THREADSAFE to CMake (default: OFF). If on, then the logic for thread-safety below is included.
  • Add memory_share class that uses RAII to claim a share of memory.
    • Claim up-to half of the unclaimed memory.
    • Claim at least the minimum amount of memory (128 MiB, or maybe a more sophisticated number?). If not currently available, then the thread has to wait for someone else to finish their calculations.
    • If the internal-memory cases use less than is claimed, then relinquish the unused amount early. Alternatively, first claim memory after all internal-memory calculations have been made.
@SSoelvsten SSoelvsten added ✨ feature New operation or other feature 🎓 student programmer Work, work... 🎓 student project Work, work... but academic! labels Apr 15, 2024
@SSoelvsten SSoelvsten added this to the v3.0 : Thread Safety milestone Apr 15, 2024
@SSoelvsten SSoelvsten added the help wanted Extra attention is needed label Apr 15, 2024
@SSoelvsten SSoelvsten pinned this issue Apr 15, 2024
@SSoelvsten
Copy link
Owner Author

SSoelvsten commented Jun 17, 2024

While talking to Riko Jacob, it can be a bad idea to just naively split the amount of memory (as described above). Iterating on his point, we should consider to:

  1. Have an upper bound on the number of concurrent jobs (set by the user / CPU specification). This could quite easily be integrated into the above solution by (1) making the minimum claimed memory be M/P where P being the maximum number of concurrent jobs and/or (2) make it also track the number of concurrently active jobs (with a semaphore).
  2. Schedule/Throttle the concurrent jobs (in a FIFO fashion?)

@SSoelvsten
Copy link
Owner Author

Note, the memory_share class almost acts as a semaphore (but one you can read and where the increment/decrement is not 1 but the amount of memory you want to use).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ feature New operation or other feature help wanted Extra attention is needed 🎓 student programmer Work, work... 🎓 student project Work, work... but academic!
Projects
None yet
Development

No branches or pull requests

1 participant