Fix endianness issue which fixes deadlock#88
Open
pranavkaruvally wants to merge 1 commit intogoogle:mainfrom
Open
Fix endianness issue which fixes deadlock#88pranavkaruvally wants to merge 1 commit intogoogle:mainfrom
pranavkaruvally wants to merge 1 commit intogoogle:mainfrom
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Author
|
The change should be to |
Author
|
Hi! I've signed the CLA now. Could someone please take a look at this when you have a chance? Thank you! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121387
The threadpool having 8 threads, 1 thread was doing the actual work while the other 7 threads were waiting until the thread which was doing the work becomes available again (Waiting for the number of active threads to change). So, the following line that the main thread was executing contained the issue:
threadpool->work_is_doneis of type_Atomic unsigned longand inside the functionfutex_wait, the variable is directly passed tosyscall(SYS_futex, address, val, ...)where the address was expected to haveuint32_t*.Although, the
threadpool->work_is_donehad a value of1, reading the upper 32-bits made it wait (andwork_is_donehas value0) and hence waits. Originally, this thread should not have blocked, should have proceeded further and should have calledfutex_wake_all to awaken the other7threads which were waiting for the completion of this thread's execution.And, looking back at older commits,
pthreadpool_atomic_uint32_tused to be_Atomic(uint32_t)oruint32_tdepending on the compiler (conditional compilation). On a specific commit it was decided to use thestdatomic.hheader file to replace this and usedtypedef atomic_uint_fast32_t threadpool_atomic_uint32_tinstead.And
atomic_uint_fast32means: an atomic, unsigned integer that is at least 32 bits and chosen for fast hardware access. Hence it is not necessarily 32-bit on every machine, on the contrary is 64-bit on most machines. Changing that to least32_t guarantees it to have 32-bits on all machines that support a 32-bit wide integer type (All linux machines I suppose).