Skip to content

[SYCL] Add a mutex to state-modifying program functions #1204

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

Merged
merged 4 commits into from
Apr 15, 2020

Conversation

sergey-semenov
Copy link
Contributor

@sergey-semenov sergey-semenov commented Feb 26, 2020

Previously, program state verification/modification was done in a
non-thread-safe way, meaning that if the user tried to compile/link/build
the same program from multiple threads, the runtime would sometimes attempt
to perform the operation twice.
This patch adds a mutex to state-modifying functions of the program class
to ensure that the invalid state is reported in such cases instead.

Signed-off-by: Sergey Semenov [email protected]

This is done in order to consistently report errors if the user
tries to compile/link/build the same program from multiple threads.

Signed-off-by: Sergey Semenov <[email protected]>
Copy link
Contributor

@s-kanaev s-kanaev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You suggest using a distinct mutex per program. Mutex is the kind of resource provided by OS.
How about an atomic state per program? It may require an additional single mutex + condition_variable. Similiar scheme is employed in kernel/program cache.

@s-kanaev
Copy link
Contributor

s-kanaev commented Mar 6, 2020

@sergey-semenov ping

@sergey-semenov
Copy link
Contributor Author

Sorry for the delay.

You suggest using a distinct mutex per program. Mutex is the kind of resource provided by OS.
How about an atomic state per program? It may require an additional single mutex + condition_variable. Similiar scheme is employed in kernel/program cache.

Can you elaborate on your concern for a mutex per program? I'm not aware of any overhead that comes with the use of multiple mutexes (aside from locking several of them in the link constructor case).

@s-kanaev
Copy link
Contributor

Can you elaborate on your concern for a mutex per program? I'm not aware of any overhead that comes with the use of multiple mutexes (aside from locking several of them in the link constructor case).

Mutex is resource provided by operating system. We believe the user won't really employ linking of thousands to millions of programs. Though the only resource a mutex really consumes is memory (see man pthread_mutex_init or man pthread_mutex_destroy, section Why no limits are defined).

Same said, atomic variable will only consume memory and will have some overhead on cache synchronization. Though a lot of threads, trying to lock the same mutex will lack concurrency (see The costs section in https://mortoray.com/2019/02/20/how-does-a-mutex-work-what-does-it-cost/).

@romanovvlad
Copy link
Contributor

@sergey-semenov ping

@romanovvlad
Copy link
Contributor

@sergey-semenov ping

Signed-off-by: Sergey Semenov <[email protected]>
Signed-off-by: Sergey Semenov <[email protected]>
@sergey-semenov sergey-semenov requested a review from bader as a code owner April 14, 2020 13:40
@sergey-semenov sergey-semenov requested a review from s-kanaev April 14, 2020 13:40
s-kanaev
s-kanaev previously approved these changes Apr 14, 2020
Copy link
Contributor

@s-kanaev s-kanaev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
Only minor comments.

Copy link
Contributor

@romanovvlad romanovvlad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
Please update first PR message with a content which will go to a final commit message.
Please include description of the problem and the way how you are fixing it.

@sergey-semenov sergey-semenov changed the title [SYCL] Add a mutex to state-dependent program functions [SYCL] Add a mutex to state-modifying program functions Apr 15, 2020
@bader bader merged commit e88a611 into intel:sycl Apr 15, 2020
@sergey-semenov sergey-semenov deleted the programmutex branch April 20, 2020 10:21
alexbatashev pushed a commit to alexbatashev/llvm that referenced this pull request Apr 21, 2020
…c_abi_checks

* origin/sycl:
  [SYCL][Driver] Enforce unique filenames when -save-temps is used (intel#1545)
  [SYCL] [xmethods] Allow replacing xmethod script (intel#1532)
  [SYCL] Add tests for inline asm feature (intel#1444)
  [SYCL][Doc] Add device_specific_kernel_queries extension. (intel#1540)
  [SYCL][USM] Remove unused header and unnecessary includes (intel#1537)
  Fix check-llvm dependencies (intel#1547)
  [SYCL] Add __SYCL_EXPORT to declaration of contextSetExtendedDeleter (intel#1531)
  [SYCL][Doc] Add static local memory query extension. (intel#1539)
  [SYCL][Doc] Add sycl_bitcast extension (intel#1541)
  [SYCL][NFC] Temporarily disable sporadically failing test (intel#1533)
  [SYCL][NFC] Adjust codeowners for sycl directory (intel#1529)
  [SYCL] Fix processing of spec consts referenced twice (intel#1524)
  [SYCL] Use correct macro name in export.hpp (intel#1527)
  [Driver][NFC] Fix -help information for -Xs options (intel#1530)
  [SYCL][Doc] Add Graph Scheduler design documentation (intel#1457)
  [SYCL] Add diagnostics for long double in device code (intel#1512)
  [SYCL] Add a mutex to state-modifying program functions (intel#1204)
  [SYCL][Test] Add Devicelib tests (intel#1256)
  [SYCL] Refactor semantic checks for variable types (intel#1513)
vmaksimo pushed a commit to vmaksimo/llvm that referenced this pull request Sep 13, 2021
…ntel#1204)

This is a patch to avoid duplication of global annotation strings in reverse
translation caused by the fact that translator translates each
UserSemantic decoration, even if a similar decoration with the same string
has also been translated.

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@2f81f31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants