Skip to content
This repository was archived by the owner on Jul 29, 2024. It is now read-only.

Shutdown threads in a graceful way#270

Merged
lijing0010 merged 1 commit into
OpenVisualCloud:masterfrom
lijing0010:shutdown_thread
Jul 23, 2019
Merged

Shutdown threads in a graceful way#270
lijing0010 merged 1 commit into
OpenVisualCloud:masterfrom
lijing0010:shutdown_thread

Conversation

@lijing0010
Copy link
Copy Markdown
Contributor

Signed-off-by: Jing Li jing.b.li@intel.com

@lijing0010 lijing0010 merged commit c0e3e4e into OpenVisualCloud:master Jul 23, 2019
Signed-off-by: Jing Li <jing.b.li@intel.com>
@lijing0010 lijing0010 deleted the shutdown_thread branch July 26, 2019 04:48
@tianjunwork tianjunwork added the Clean up A cleaner implementation or improved functionality label Jul 29, 2019
Austin-Hu added a commit to Austin-Hu/SVT-HEVC that referenced this pull request Nov 5, 2019
(When receiving only 1 frame input, )SvtHevcEncApp or any application
may invokes EbDeinitEncoder() ahead of all the kernel threads complete
processing. And EbDeinitEncoder() would free all the recorded memory
objects which may be still used by some threads, so that race condition
happens.

So fixed (worked around) this issue by terminating the kernel threads
before freeing memories. Ideally, there should be some object reference
and unreference mechanism to make the objects access safe.

Note:
  1. EbObjectIncLiveCount() couldn't be helpful to address such race
     condition, because it just avoids that an EbObjectWrapper_t object
     wouldn't be returned back to an empty queue prematurely;
  2. EB_SEND_END_OBJ() plus EB_CHECK_END_OBJ() (induced in PR OpenVisualCloud#270) could
     not avoid such race condition, either. Because the objects can be
     freed at any moment when a kernel thread is running and needs to
     access to it.

Signed-off-by: Austin Hu <austin.hu@intel.com>
tianjunwork pushed a commit that referenced this pull request Nov 12, 2019
(When receiving only 1 frame input) SvtHevcEncApp or any application
may invokes EbDeinitEncoder() ahead of all the kernel threads complete
processing. And EbDeinitEncoder() would free all the recorded memory
objects which may be still used by some threads, so that race condition
happens.

So fixed (worked around) this issue by terminating the kernel threads
before freeing memories. Ideally, there should be some object reference
and unreference mechanism to make the objects access safe.

Note:
  1. EbObjectIncLiveCount() couldn't be helpful to address such race
     condition, because it just avoids that an EbObjectWrapper_t object
     wouldn't be returned back to an empty queue prematurely;
  2. EB_SEND_END_OBJ() plus EB_CHECK_END_OBJ() (induced in PR #270) could
     not avoid such race condition, either. Because the objects can be
     freed at any moment when a kernel thread is running and needs to
     access to it.

Signed-off-by: Austin Hu <austin.hu@intel.com>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Clean up A cleaner implementation or improved functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants