Skip to content

[TRT EP] Fix multithreading bug of getting the corrupted trt engine instance - #17507

Merged
jywu-mysoft merged 1 commit into
mainfrom
chi/fix_trt_ep_multithreading
Sep 12, 2023
Merged

[TRT EP] Fix multithreading bug of getting the corrupted trt engine instance#17507
jywu-mysoft merged 1 commit into
mainfrom
chi/fix_trt_ep_multithreading

Conversation

@chilo-ms

@chilo-ms chilo-ms commented Sep 12, 2023

Copy link
Copy Markdown
Contributor

Revert to the old TRT EP behavior of securing the whole compute_function by lock_guard.

Current TRT EP which only puts lock_guard around a critical section (obvious wrong) inside compute_function.
The issue can happen where one thread is updating the engine in compute_function whereas another thread still accesses the stale/corrupted engine instance in compute_function, for example, the code outside the critical section, int total_bindings = trt_engine->getNbBindings().

So, make the whole compute_function the critical section should be okay.

@chilo-ms chilo-ms changed the title [TRT EP] Fix multithreading bug of getting the updated trt engine instance [TRT EP] Fix multithreading bug of getting the corrputed trt engine instance Sep 12, 2023
@chilo-ms chilo-ms changed the title [TRT EP] Fix multithreading bug of getting the corrputed trt engine instance [TRT EP] Fix multithreading bug of getting the corrupted trt engine instance Sep 12, 2023
@jywu-mysoft
jywu-mysoft merged commit aa5e364 into main Sep 12, 2023
@jywu-mysoft
jywu-mysoft deleted the chi/fix_trt_ep_multithreading branch September 12, 2023 14:37
jywu-mysoft pushed a commit that referenced this pull request Sep 12, 2023
Cherry-pick #17507  for rel-1.16.0.

Note: The PR 17507 contains the part of engine decryption refactor that
we don't want to include it in ORT 1.16 release. This cherry pick PR
excludes this part.
@natke natke added the triage:approved Approved for cherrypicks for release label Sep 12, 2023
kleiti pushed a commit to kleiti/onnxruntime that referenced this pull request Mar 22, 2024
…nstance (microsoft#17507)

Revert to the old TRT EP behavior of securing the whole compute_function
by lock_guard.

Current TRT EP which only puts lock_guard around a critical section
(obvious wrong) inside compute_function.
The issue can happen where one thread is updating the engine in
compute_function whereas another thread still accesses the
stale/corrupted engine instance in compute_function, for example, the
code outside the critical section, `int total_bindings =
trt_engine->getNbBindings()`.

So, make the whole compute_function the critical section should be okay.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triage:approved Approved for cherrypicks for release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants