|
|
@ -26,13 +26,14 @@ namespace rocksdb { |
|
|
|
// (2) a ThreadLocalPtr is destroyed
|
|
|
|
// (2) a ThreadLocalPtr is destroyed
|
|
|
|
typedef void (*UnrefHandler)(void* ptr); |
|
|
|
typedef void (*UnrefHandler)(void* ptr); |
|
|
|
|
|
|
|
|
|
|
|
// Thread local storage that only stores value of pointer type. The storage
|
|
|
|
// ThreadLocalPtr stores only values of pointer type. Different from
|
|
|
|
// distinguish data coming from different thread and different ThreadLocalPtr
|
|
|
|
// the usual thread-local-storage, ThreadLocalPtr has the ability to
|
|
|
|
// instances. For example, if a regular thread_local variable A is declared
|
|
|
|
// distinguish data coming from different threads and different
|
|
|
|
// in DBImpl, two DBImpl objects would share the same A. ThreadLocalPtr avoids
|
|
|
|
// ThreadLocalPtr instances. For example, if a regular thread_local
|
|
|
|
// the confliction. The total storage size equals to # of threads * # of
|
|
|
|
// variable A is declared in DBImpl, two DBImpl objects would share
|
|
|
|
// ThreadLocalPtr instances. It is not efficient in terms of space, but it
|
|
|
|
// the same A. However, a ThreadLocalPtr that is defined under the
|
|
|
|
// should serve most of our use cases well and keep code simple.
|
|
|
|
// scope of DBImpl can avoid such confliction. As a result, its memory
|
|
|
|
|
|
|
|
// usage would be O(# of threads * # of ThreadLocalPtr instances).
|
|
|
|
class ThreadLocalPtr { |
|
|
|
class ThreadLocalPtr { |
|
|
|
public: |
|
|
|
public: |
|
|
|
explicit ThreadLocalPtr(UnrefHandler handler = nullptr); |
|
|
|
explicit ThreadLocalPtr(UnrefHandler handler = nullptr); |
|
|
|