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

Fix GC related deadlock in the libevent driver #1756

Merged
merged 2 commits into from May 11, 2017

Conversation

Projects
None yet
1 participant
@s-ludwig
Member

s-ludwig commented May 7, 2017

@DBankov: This should hopefully fix the deadlock situation. Tested on my laptop and I get a scale factor of around 1,6x (performance still worse than it used to be). I can also observe the growing memory consumption.

s-ludwig added some commits May 7, 2017

Use a non-GC allocator for s_threadObjects to avoid potential deadlock.
The original deadlock situation that this change avoids:

Thread 1: GC collection (GC lock taken) -> Libevent2Object.~this -> Libevent2Driver.unregisterObject -> synchronized(s_threadObjectsMutex)
Thread 2: Libevent2Driver.registerObject -> synchronized(s_threadObejctsMutex) -> s_threadObjects.insert -> GC allocate -> acquire GC lock

Sidenote: ArraySet should be replaced by HashMap for efficiency reasons.

@s-ludwig s-ludwig merged commit 3ee31ae into master May 11, 2017

3 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@s-ludwig s-ludwig deleted the fix_libevent_deadlock branch May 11, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment