1. 03 2月, 2017 1 次提交
  2. 14 12月, 2016 1 次提交
  3. 30 10月, 2016 1 次提交
  4. 23 8月, 2016 1 次提交
    • A
      Fold function for thread-local data · 6584cec8
      Andrew Kryczka 提交于
      Summary:
      This function allows the user to provide a custom function to fold all
      threads' local data. It will be used in my next diff for aggregating statistics
      stored in thread-local data. Note the test case uses atomics as thread-local
      values due to the synchronization requirement (documented in code).
      
      Test Plan: unit test
      
      Reviewers: yhchiang, sdong, kradhakrishnan
      
      Reviewed By: kradhakrishnan
      
      Subscribers: andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D62049
      6584cec8
  5. 29 7月, 2016 1 次提交
    • A
      Simplify thread-local static initialization · afad5bd1
      Andrew Kryczka 提交于
      Summary:
      The call stack used to look like this during static initialization:
      
        #0  0x00000000008032d1 in rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta() (this=0x7ffff683b300) at util/thread_local.cc:172
        #1  0x00000000008030a7 in rocksdb::ThreadLocalPtr::Instance() () at util/thread_local.cc:135
        #2  0x000000000080310f in rocksdb::ThreadLocalPtr::StaticMeta::Mutex() () at util/thread_local.cc:141
        #3  0x0000000000803103 in rocksdb::ThreadLocalPtr::StaticMeta::InitSingletons() () at util/thread_local.cc:139
        #4  0x000000000080305d in rocksdb::ThreadLocalPtr::InitSingletons() () at util/thread_local.cc:106
      
      It involves outer/inner classes and the call stacks goes
      outer->inner->outer->inner, which is too difficult to understand. We can avoid
      a level of back-and-forth by skipping StaticMeta::InitSingletons(), which
      doesn't initialize anything beyond what ThreadLocalPtr::Instance() already
      initializes.
      
      Now the call stack looks like this during static initialization:
      
        #0  0x00000000008032c5 in rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta() (this=0x7ffff683b300) at util/thread_local.cc:170
        #1  0x00000000008030a7 in rocksdb::ThreadLocalPtr::Instance() () at util/thread_local.cc:135
        #2  0x000000000080305d in rocksdb::ThreadLocalPtr::InitSingletons() () at util/thread_local.cc:106
      
      Test Plan:
      unit tests
      
      verify StaticMeta::mutex_ is still initialized in DefaultEnv() (StaticMeta::mutex_ is the only variable intended to be initialized via StaticMeta::InitSingletons() which I removed)
      
        #0  0x00000000005cee17 in rocksdb::port::Mutex::Mutex(bool) (this=0x7ffff69500b0, adaptive=false) at port/port_posix.cc:52
        #1  0x0000000000769cf8 in rocksdb::ThreadLocalPtr::StaticMeta::StaticMeta() (this=0x7ffff6950000) at util/thread_local.cc:168
        #2  0x0000000000769a53 in rocksdb::ThreadLocalPtr::Instance() () at util/thread_local.cc:133
        #3  0x0000000000769a09 in rocksdb::ThreadLocalPtr::InitSingletons() () at util/thread_local.cc:105
        #4  0x0000000000647d98 in rocksdb::Env::Default() () at util/env_posix.cc:845
      
      Reviewers: lightmark, yhchiang, sdong
      
      Reviewed By: sdong
      
      Subscribers: arahut, IslamAbdelRahman, yiwu, andrewkr, dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D60813
      afad5bd1
  6. 11 2月, 2016 1 次提交
    • Y
      Fixed a dependency issue of ThreadLocalPtr · 90810039
      Yueh-Hsuan Chiang 提交于
      Summary:
      When a child thread that uses ThreadLocalPtr, ThreadLocalPtr::OnThreadExit
      will be called when that child thread is destroyed.  However,
      OnThreadExit will try to access a static singleton of ThreadLocalPtr,
      which will be destroyed when the main thread exit.  As a result,
      when a child thread that uses ThreadLocalPtr exits AFTER the main thread
      exits, illegal memory access will occur.
      
      This diff includes a test that reproduce this legacy bug.
      
          ==2095206==ERROR: AddressSanitizer: heap-use-after-free on address
          0x608000007fa0 at pc 0x959b79 bp 0x7f5fa7426b60 sp 0x7f5fa7426b58
          READ of size 8 at 0x608000007fa0 thread T1
      
      This patch fix this issue by having the thread local mutex never be deleted
      (but will leak small piece of memory at the end.)   The patch also describe
      a better solution (thread_local) in the comment that requires gcc 4.8.1 and
      in latest clang as a future work once we agree to move toward gcc 4.8.
      
      Test Plan:
      COMPILE_WITH_ASAN=1 make thread_local_test -j32
      ./thread_local_test --gtest_filter="*MainThreadDiesFirst"
      
      Reviewers: anthony, hermanlee4, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D53013
      90810039
  7. 10 2月, 2016 1 次提交
  8. 11 12月, 2015 1 次提交
    • Y
      Ensure the destruction order of PosixEnv and ThreadLocalPtr · 00d6edf6
      Yueh-Hsuan Chiang 提交于
      Summary:
      By default, RocksDB initializes the singletons of ThreadLocalPtr first, then initializes PosixEnv
      via static initializer.  Destructor terminates objects in reverse order, so terminating PosixEnv
      (calling pthread_mutex_lock), then ThreadLocal (calling pthread_mutex_destroy).
      
      However, in certain case, application might initialize PosixEnv first, then ThreadLocalPtr.
      This will cause core dump at the end of the program (eg. https://github.com/facebook/mysql-5.6/issues/122)
      
      This patch fix this issue by ensuring the destruction order by moving the global static singletons
      to function static singletons.  Since function static singletons are initialized when the function is first
      called, this property allows us invoke to enforce the construction of the static PosixEnv and the
      singletons of ThreadLocalPtr by calling the function where the ThreadLocalPtr singletons belongs
      right before we initialize the static PosixEnv.
      
      Test Plan: Verified in the MyRocks.
      
      Reviewers: yoshinorim, IslamAbdelRahman, rven, kradhakrishnan, anthony, sdong, MarkCallaghan
      
      Reviewed By: anthony
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D51789
      00d6edf6
  9. 12 8月, 2015 2 次提交
    • Y
      Fixed clang-build error in util/thread_local.cc · e61fafbe
      Yueh-Hsuan Chiang 提交于
      Summary:
      This patch fixes the following clang-build error in util/thread_local.cc by using a cleaner macro blocker:
      
      12:26:31 util/thread_local.cc:157:19: error: declaration shadows a static data member of 'rocksdb::ThreadLocalPtr::StaticMeta' [-Werror,-Wshadow]
      12:26:31       ThreadData* tls_ =
      12:26:31                   ^
      12:26:31 util/thread_local.cc:19:66: note: previous declaration is here
      12:26:31 __thread ThreadLocalPtr::ThreadData* ThreadLocalPtr::StaticMeta::tls_ = nullptr;
      12:26:31                                                                  ^
      
      Test Plan: db_test
      
      Reviewers: sdong, anthony, IslamAbdelRahman, igor
      
      Reviewed By: igor
      
      Subscribers: dhruba
      
      Differential Revision: https://reviews.facebook.net/D44043
      e61fafbe
    • Y
      Fixed Segmentation Fault in db_stress on OSX. · b47d65b3
      Yueh-Hsuan Chiang 提交于
      Summary:
      This patch provides a simplier solution to the memory leak
      issue identified in patch https://reviews.facebook.net/D43677,
      where a static function local variable can be used instead of
      using a global static unique_ptr.
      
      Test Plan: run db_stress on mac
      
      Reviewers: igor, sdong, anthony, IslamAbdelRahman, maykov
      
      Reviewed By: maykov
      
      Subscribers: dhruba, leveldb
      
      Differential Revision: https://reviews.facebook.net/D43995
      b47d65b3
  10. 08 8月, 2015 1 次提交
    • N
      Fix OSX + Windows build · ac04a6cf
      Nate Rosenblum 提交于
      Commit 257ee895 added a static destruction helper to avoid notional
      "leaks" of TLS on main thread exit. This helper fails to compile on
      OS X (and presumably Windows, though I haven't checked), which lacks
      the __thread storage class StaticMeta::tls_ member.
      
      This patch fixes the builds. Do note that the static cleanup mechanism
      may be somewhat brittle and atexit(3) may be a more suitable approach
      to releasing the main thread's TLS if it's highly desirable for this
      memory to not be reported "reachable" by Valgrind at exit.
      ac04a6cf
  11. 07 8月, 2015 1 次提交
    • A
      Fixed memory leaks · 257ee895
      Alexey Maykov 提交于
      Summary:
      MyRocks valgrind run was showing memory leaks. The fixes are mostly self-explaining.
      There is only a single usage of ThreadLocalPtr. Potentially, we may think about replacing this use with thread_local, but it will be a bigger change. Another option to consider is using thread_local instead of __thread in ThreadLocalPtr implementation. This way, tls_ can be stored using std::unique_ptr and no destructor would be required.
      
      Test Plan:
       - make check
       - MyRocks valgrind run doesn't report leaks
      
      Reviewers: rven, sdong
      
      Reviewed By: sdong
      
      Subscribers: dhruba
      
      Differential Revision: https://reviews.facebook.net/D43677
      257ee895
  12. 14 7月, 2015 1 次提交
    • S
      "make format" against last 10 commits · f9728640
      sdong 提交于
      Summary: This helps Windows port to format their changes, as discussed. Might have formatted some other codes too becasue last 10 commits include more.
      
      Test Plan: Build it.
      
      Reviewers: anthony, IslamAbdelRahman, kradhakrishnan, yhchiang, igor
      
      Reviewed By: igor
      
      Subscribers: leveldb, dhruba
      
      Differential Revision: https://reviews.facebook.net/D41961
      f9728640
  13. 08 7月, 2015 1 次提交
  14. 02 7月, 2015 1 次提交
    • D
      Windows Port from Microsoft · 18285c1e
      Dmitri Smirnov 提交于
       Summary: Make RocksDb build and run on Windows to be functionally
       complete and performant. All existing test cases run with no
       regressions. Performance numbers are in the pull-request.
      
       Test plan: make all of the existing unit tests pass, obtain perf numbers.
      
       Co-authored-by: Praveen Rao praveensinghrao@outlook.com
       Co-authored-by: Sherlock Huang baihan.huang@gmail.com
       Co-authored-by: Alex Zinoviev alexander.zinoviev@me.com
       Co-authored-by: Dmitri Smirnov dmitrism@microsoft.com
      18285c1e
  15. 28 1月, 2015 1 次提交
    • S
      Use ustricter consistency in thread local operations · 4c49feda
      sdong 提交于
      Summary:
      ThreadSanitizer complains data race of super version and version's destructor with Get(). This patch will fix those warning.
      
      The warning is likely from ColumnFamilyData::ReturnThreadLocalSuperVersion(). With relaxed consistency of CAS, reading the data of the super version can technically happen after swapping it in, enabling the background thread to clean it up.
      
      Test Plan: make all check
      
      Reviewers: rven, igor, yhchiang
      
      Reviewed By: yhchiang
      
      Subscribers: leveldb, dhruba
      
      Differential Revision: https://reviews.facebook.net/D32265
      4c49feda
  16. 13 1月, 2015 1 次提交
  17. 05 12月, 2014 1 次提交
  18. 23 4月, 2014 3 次提交
  19. 08 3月, 2014 1 次提交
  20. 28 2月, 2014 1 次提交
  21. 26 2月, 2014 1 次提交
    • L
      thread local pointer storage · b2795b79
      Lei Jin 提交于
      Summary:
      This is not a generic thread local implementation in the sense that it
      only takes pointer. But it does support multiple instances per thread
      and lets user plugin function to perform cleanup when thread exits or an
      instance gets destroyed.
      
      Test Plan: unit test for now
      
      Reviewers: haobo, igor, sdong, dhruba
      
      Reviewed By: igor
      
      CC: leveldb, kailiu
      
      Differential Revision: https://reviews.facebook.net/D16131
      b2795b79