Creating a lock-free memory pool using C++11 featuresBoost::pool based STL vector allocatorImplementation of a lock-free fixed-sized allocatorImplementation of a lock-free fixed-sized allocator - follow-up - with commented codeLock-free MultiConsumer/MultiProducer queueMPMC lock-free queueLock-free SPMC queueLock-free list in C++Task-Based Multithreading Library - Implemented using FibersLock-free segmented shared memory buffer in C++Lock free consumer producer using memory barrier

Can a virus destroy the BIOS of a modern computer?

Rotate ASCII Art by 45 Degrees

How does a dynamic QR code work?

How dangerous is XSS

Send out email when Apex Queueable fails and test it

Why is the sentence "Das ist eine Nase" correct?

Where would I need my direct neural interface to be implanted?

Is it "common practice in Fourier transform spectroscopy to multiply the measured interferogram by an apodizing function"? If so, why?

Placement of More Information/Help Icon button for Radio Buttons

Does int main() need a declaration on C++?

What do you call someone who asks many questions?

Getting extremely large arrows with tikzcd

How to Prove P(a) → ∀x(P(x) ∨ ¬(x = a)) using Natural Deduction

Mathematica command that allows it to read my intentions

Why was the shrink from 8″ made only to 5.25″ and not smaller (4″ or less)

Do Iron Man suits sport waste management systems?

How to travel to Japan while expressing milk?

Implication of namely

Notepad++ delete until colon for every line with replace all

Unlock My Phone! February 2018

Why didn't Boeing produce its own regional jet?

How to remove border from elements in the last row?

How can I deal with my CEO asking me to hire someone with a higher salary than me, a co-founder?

What's the meaning of "Sollensaussagen"?



Creating a lock-free memory pool using C++11 features


Boost::pool based STL vector allocatorImplementation of a lock-free fixed-sized allocatorImplementation of a lock-free fixed-sized allocator - follow-up - with commented codeLock-free MultiConsumer/MultiProducer queueMPMC lock-free queueLock-free SPMC queueLock-free list in C++Task-Based Multithreading Library - Implemented using FibersLock-free segmented shared memory buffer in C++Lock free consumer producer using memory barrier













3












$begingroup$


I have created a thread-safe and lock-free memory pool program using C++11 features. A couple of notable features:




  • g_memStack is a stack that contains the memory unit; we can allocate memory from it.


  • g_waitingReclaims is something like a stack that contains units waiting reclaim from the memory unit.


  • g_allocatingCounter is a counter to specify the thread number in the Allocate function. It will have a value of 1 to indicate that there is no other thread waiting to allocate memory from the pool. This indicates that it is safe to reclaim memory in g_waitingReclaims.

I am looking for a review of both correctness and style. Specifically:



  • Is there anything wrong with the memory ordering in g_allocatingCounter.fetch_add(1, std::memory_order_relaxed (the first line in the Allocate function?)?


  • Is it possible that the next line (MemUnit *unit = g_memStack.load(std::memory_order_acquire); could be re-ordered to execute first at runtime?


  • If so, how would I fix that? Could I just change the memory order to std::memory_order_aquery? Would that require another release operation to cooperate with it (I don't think so, because cppreference said std::memory_order_acquire will prevent read and write from reordering before it)?


  • Anything else?


#include <string>
#include <thread>
#include <vector>
#include <cstdlib>
#include <atomic>
#include <cassert>

struct MemUnit

MemUnit *m_next;//next unit
void *m_data;//memory for data
;

void *g_buffernullptr;
std::atomic<MemUnit *> g_memStack;
std::atomic<MemUnit *> g_waitingReclaims;
std::atomic<uint32_t> g_allocatingCounter;

void InitMemPool(size_t poolSize, size_t blockSize);
void UninitMemPool();

MemUnit *StepToTail(MemUnit* listHead);
void Reclaim(MemUnit* listHead, MemUnit* listTail);
void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail);

MemUnit *Allocate()

g_allocatingCounter.fetch_add(1, std::memory_order_relaxed);//Warning: Something wrong with the memory order. It maybe reorder after the next line at runtime.
MemUnit *unit = g_memStack.load(std::memory_order_acquire);
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

MemUnit *pendingList = g_waitingReclaims.exchange(nullptr, std::memory_order_acquire);
const bool canReclaim = g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed) == 1;//this operation can not reorder before exchange operation Just because the 'memory_order_acquire'
//If 'canReclaim' is true, it's ABA problem free. Because there is nobody in 'Allocate' hold same pointer within pending list.
if (canReclaim && pendingList != nullptr)

canReclaim ? Reclaim(pendingList, StepToTail(pendingList)) : GiveBackToWaitings(pendingList, StepToTail(pendingList));

return unit;

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);//this operation can not reorder before 'compare_exchange_weak' Just because the 'memory_order_acquire'
return unit;


void FreeMemUnit(MemUnit* item)

item->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(item->m_next, item, std::memory_order_release, std::memory_order_relaxed));


MemUnit *StepToTail(MemUnit* listHead)

assert(listHead != nullptr);
while (listHead->m_next) listHead = listHead->m_next;
return listHead;


void Reclaim(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_memStack.load(std::memory_order_relaxed);
while (!g_memStack.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_release, std::memory_order_relaxed));


void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_relaxed, std::memory_order_relaxed));
//Yes, it's 'relaxed' memory order when it's success.


void InitMemPool(size_t poolSize, size_t blockSize)

const size_t unitSize = sizeof(MemUnit) + blockSize;
g_buffer = reinterpret_cast<uint8_t *>(std::malloc(unitSize * poolSize));

MemUnit* next = nullptr;
uint8_t* rawBuffer = reinterpret_cast<uint8_t*>(g_buffer);
for (size_t i = 0; i != poolSize; ++i)

MemUnit* pObj = reinterpret_cast<MemUnit *>(rawBuffer);
pObj->m_next = next;
next = pObj;
rawBuffer += unitSize;

g_memStack.store(next, std::memory_order_relaxed);


void UninitMemPool()

assert(g_allocatingCounter.load(std::memory_order_relaxed) == 0);

g_memStack.store(nullptr, std::memory_order_relaxed);
g_waitingReclaims.store(nullptr, std::memory_order_relaxed);
std::free(g_buffer);
g_buffer = nullptr;




void WorkThread()

for (size_t i = 0; i != 128; ++i)

MemUnit *unit = Allocate();
if (unit != nullptr)

//do something use unit.m_data;
FreeMemUnit(unit);




int main()

InitMemPool(128, 1024);

std::vector<std::thread> allThreads;
for (size_t i = 0; i != 8; ++i)

std::thread t(WorkThread);
allThreads.push_back(std::move(t));

for (auto &t : allThreads)

t.join();

UninitMemPool();
return 0;










share|improve this question









$endgroup$



migrated from stackoverflow.com 15 mins ago


This question came from our site for professional and enthusiast programmers.













  • 1




    $begingroup$
    Please check your initialization of the atomics to be correct. I don't know if it is, but there is usually some very weird stuff going on if done wrong.
    $endgroup$
    – Thomas Lang
    21 hours ago










  • $begingroup$
    @ThomasLang: the 3 atomic<T> variables are all pointer-sized or 32-bit, and have static storage duration. On normal C++ implementations (like x86 gcc or MSVC, or ARM, or whatever), they will be lock-free, and thus zero-initialization of their object representation will give correct behaviour. (As far as C++ language rules, yes, it's a good idea to make sure you init them correctly, but this doesn't explain any weirdness observed on real systems.)
    $endgroup$
    – Peter Cordes
    15 hours ago










  • $begingroup$
    @Peter Cordes: I have completed the code. Yes, i didn't observe anything weird. The program is just a practice and i can't guarantee it works as what i think(Some times it's really hard to find bugs behind lock-free codes). So i came here and wanted to known what others thinking about this(Yes, it's really like a code review).
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    @Cody: nice edit! Typo: aquery -> acquire (I don't have 2k rep on this .SE to fix it myself.)
    $endgroup$
    – Peter Cordes
    11 mins ago















3












$begingroup$


I have created a thread-safe and lock-free memory pool program using C++11 features. A couple of notable features:




  • g_memStack is a stack that contains the memory unit; we can allocate memory from it.


  • g_waitingReclaims is something like a stack that contains units waiting reclaim from the memory unit.


  • g_allocatingCounter is a counter to specify the thread number in the Allocate function. It will have a value of 1 to indicate that there is no other thread waiting to allocate memory from the pool. This indicates that it is safe to reclaim memory in g_waitingReclaims.

I am looking for a review of both correctness and style. Specifically:



  • Is there anything wrong with the memory ordering in g_allocatingCounter.fetch_add(1, std::memory_order_relaxed (the first line in the Allocate function?)?


  • Is it possible that the next line (MemUnit *unit = g_memStack.load(std::memory_order_acquire); could be re-ordered to execute first at runtime?


  • If so, how would I fix that? Could I just change the memory order to std::memory_order_aquery? Would that require another release operation to cooperate with it (I don't think so, because cppreference said std::memory_order_acquire will prevent read and write from reordering before it)?


  • Anything else?


#include <string>
#include <thread>
#include <vector>
#include <cstdlib>
#include <atomic>
#include <cassert>

struct MemUnit

MemUnit *m_next;//next unit
void *m_data;//memory for data
;

void *g_buffernullptr;
std::atomic<MemUnit *> g_memStack;
std::atomic<MemUnit *> g_waitingReclaims;
std::atomic<uint32_t> g_allocatingCounter;

void InitMemPool(size_t poolSize, size_t blockSize);
void UninitMemPool();

MemUnit *StepToTail(MemUnit* listHead);
void Reclaim(MemUnit* listHead, MemUnit* listTail);
void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail);

MemUnit *Allocate()

g_allocatingCounter.fetch_add(1, std::memory_order_relaxed);//Warning: Something wrong with the memory order. It maybe reorder after the next line at runtime.
MemUnit *unit = g_memStack.load(std::memory_order_acquire);
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

MemUnit *pendingList = g_waitingReclaims.exchange(nullptr, std::memory_order_acquire);
const bool canReclaim = g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed) == 1;//this operation can not reorder before exchange operation Just because the 'memory_order_acquire'
//If 'canReclaim' is true, it's ABA problem free. Because there is nobody in 'Allocate' hold same pointer within pending list.
if (canReclaim && pendingList != nullptr)

canReclaim ? Reclaim(pendingList, StepToTail(pendingList)) : GiveBackToWaitings(pendingList, StepToTail(pendingList));

return unit;

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);//this operation can not reorder before 'compare_exchange_weak' Just because the 'memory_order_acquire'
return unit;


void FreeMemUnit(MemUnit* item)

item->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(item->m_next, item, std::memory_order_release, std::memory_order_relaxed));


MemUnit *StepToTail(MemUnit* listHead)

assert(listHead != nullptr);
while (listHead->m_next) listHead = listHead->m_next;
return listHead;


void Reclaim(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_memStack.load(std::memory_order_relaxed);
while (!g_memStack.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_release, std::memory_order_relaxed));


void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_relaxed, std::memory_order_relaxed));
//Yes, it's 'relaxed' memory order when it's success.


void InitMemPool(size_t poolSize, size_t blockSize)

const size_t unitSize = sizeof(MemUnit) + blockSize;
g_buffer = reinterpret_cast<uint8_t *>(std::malloc(unitSize * poolSize));

MemUnit* next = nullptr;
uint8_t* rawBuffer = reinterpret_cast<uint8_t*>(g_buffer);
for (size_t i = 0; i != poolSize; ++i)

MemUnit* pObj = reinterpret_cast<MemUnit *>(rawBuffer);
pObj->m_next = next;
next = pObj;
rawBuffer += unitSize;

g_memStack.store(next, std::memory_order_relaxed);


void UninitMemPool()

assert(g_allocatingCounter.load(std::memory_order_relaxed) == 0);

g_memStack.store(nullptr, std::memory_order_relaxed);
g_waitingReclaims.store(nullptr, std::memory_order_relaxed);
std::free(g_buffer);
g_buffer = nullptr;




void WorkThread()

for (size_t i = 0; i != 128; ++i)

MemUnit *unit = Allocate();
if (unit != nullptr)

//do something use unit.m_data;
FreeMemUnit(unit);




int main()

InitMemPool(128, 1024);

std::vector<std::thread> allThreads;
for (size_t i = 0; i != 8; ++i)

std::thread t(WorkThread);
allThreads.push_back(std::move(t));

for (auto &t : allThreads)

t.join();

UninitMemPool();
return 0;










share|improve this question









$endgroup$



migrated from stackoverflow.com 15 mins ago


This question came from our site for professional and enthusiast programmers.













  • 1




    $begingroup$
    Please check your initialization of the atomics to be correct. I don't know if it is, but there is usually some very weird stuff going on if done wrong.
    $endgroup$
    – Thomas Lang
    21 hours ago










  • $begingroup$
    @ThomasLang: the 3 atomic<T> variables are all pointer-sized or 32-bit, and have static storage duration. On normal C++ implementations (like x86 gcc or MSVC, or ARM, or whatever), they will be lock-free, and thus zero-initialization of their object representation will give correct behaviour. (As far as C++ language rules, yes, it's a good idea to make sure you init them correctly, but this doesn't explain any weirdness observed on real systems.)
    $endgroup$
    – Peter Cordes
    15 hours ago










  • $begingroup$
    @Peter Cordes: I have completed the code. Yes, i didn't observe anything weird. The program is just a practice and i can't guarantee it works as what i think(Some times it's really hard to find bugs behind lock-free codes). So i came here and wanted to known what others thinking about this(Yes, it's really like a code review).
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    @Cody: nice edit! Typo: aquery -> acquire (I don't have 2k rep on this .SE to fix it myself.)
    $endgroup$
    – Peter Cordes
    11 mins ago













3












3








3





$begingroup$


I have created a thread-safe and lock-free memory pool program using C++11 features. A couple of notable features:




  • g_memStack is a stack that contains the memory unit; we can allocate memory from it.


  • g_waitingReclaims is something like a stack that contains units waiting reclaim from the memory unit.


  • g_allocatingCounter is a counter to specify the thread number in the Allocate function. It will have a value of 1 to indicate that there is no other thread waiting to allocate memory from the pool. This indicates that it is safe to reclaim memory in g_waitingReclaims.

I am looking for a review of both correctness and style. Specifically:



  • Is there anything wrong with the memory ordering in g_allocatingCounter.fetch_add(1, std::memory_order_relaxed (the first line in the Allocate function?)?


  • Is it possible that the next line (MemUnit *unit = g_memStack.load(std::memory_order_acquire); could be re-ordered to execute first at runtime?


  • If so, how would I fix that? Could I just change the memory order to std::memory_order_aquery? Would that require another release operation to cooperate with it (I don't think so, because cppreference said std::memory_order_acquire will prevent read and write from reordering before it)?


  • Anything else?


#include <string>
#include <thread>
#include <vector>
#include <cstdlib>
#include <atomic>
#include <cassert>

struct MemUnit

MemUnit *m_next;//next unit
void *m_data;//memory for data
;

void *g_buffernullptr;
std::atomic<MemUnit *> g_memStack;
std::atomic<MemUnit *> g_waitingReclaims;
std::atomic<uint32_t> g_allocatingCounter;

void InitMemPool(size_t poolSize, size_t blockSize);
void UninitMemPool();

MemUnit *StepToTail(MemUnit* listHead);
void Reclaim(MemUnit* listHead, MemUnit* listTail);
void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail);

MemUnit *Allocate()

g_allocatingCounter.fetch_add(1, std::memory_order_relaxed);//Warning: Something wrong with the memory order. It maybe reorder after the next line at runtime.
MemUnit *unit = g_memStack.load(std::memory_order_acquire);
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

MemUnit *pendingList = g_waitingReclaims.exchange(nullptr, std::memory_order_acquire);
const bool canReclaim = g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed) == 1;//this operation can not reorder before exchange operation Just because the 'memory_order_acquire'
//If 'canReclaim' is true, it's ABA problem free. Because there is nobody in 'Allocate' hold same pointer within pending list.
if (canReclaim && pendingList != nullptr)

canReclaim ? Reclaim(pendingList, StepToTail(pendingList)) : GiveBackToWaitings(pendingList, StepToTail(pendingList));

return unit;

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);//this operation can not reorder before 'compare_exchange_weak' Just because the 'memory_order_acquire'
return unit;


void FreeMemUnit(MemUnit* item)

item->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(item->m_next, item, std::memory_order_release, std::memory_order_relaxed));


MemUnit *StepToTail(MemUnit* listHead)

assert(listHead != nullptr);
while (listHead->m_next) listHead = listHead->m_next;
return listHead;


void Reclaim(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_memStack.load(std::memory_order_relaxed);
while (!g_memStack.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_release, std::memory_order_relaxed));


void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_relaxed, std::memory_order_relaxed));
//Yes, it's 'relaxed' memory order when it's success.


void InitMemPool(size_t poolSize, size_t blockSize)

const size_t unitSize = sizeof(MemUnit) + blockSize;
g_buffer = reinterpret_cast<uint8_t *>(std::malloc(unitSize * poolSize));

MemUnit* next = nullptr;
uint8_t* rawBuffer = reinterpret_cast<uint8_t*>(g_buffer);
for (size_t i = 0; i != poolSize; ++i)

MemUnit* pObj = reinterpret_cast<MemUnit *>(rawBuffer);
pObj->m_next = next;
next = pObj;
rawBuffer += unitSize;

g_memStack.store(next, std::memory_order_relaxed);


void UninitMemPool()

assert(g_allocatingCounter.load(std::memory_order_relaxed) == 0);

g_memStack.store(nullptr, std::memory_order_relaxed);
g_waitingReclaims.store(nullptr, std::memory_order_relaxed);
std::free(g_buffer);
g_buffer = nullptr;




void WorkThread()

for (size_t i = 0; i != 128; ++i)

MemUnit *unit = Allocate();
if (unit != nullptr)

//do something use unit.m_data;
FreeMemUnit(unit);




int main()

InitMemPool(128, 1024);

std::vector<std::thread> allThreads;
for (size_t i = 0; i != 8; ++i)

std::thread t(WorkThread);
allThreads.push_back(std::move(t));

for (auto &t : allThreads)

t.join();

UninitMemPool();
return 0;










share|improve this question









$endgroup$




I have created a thread-safe and lock-free memory pool program using C++11 features. A couple of notable features:




  • g_memStack is a stack that contains the memory unit; we can allocate memory from it.


  • g_waitingReclaims is something like a stack that contains units waiting reclaim from the memory unit.


  • g_allocatingCounter is a counter to specify the thread number in the Allocate function. It will have a value of 1 to indicate that there is no other thread waiting to allocate memory from the pool. This indicates that it is safe to reclaim memory in g_waitingReclaims.

I am looking for a review of both correctness and style. Specifically:



  • Is there anything wrong with the memory ordering in g_allocatingCounter.fetch_add(1, std::memory_order_relaxed (the first line in the Allocate function?)?


  • Is it possible that the next line (MemUnit *unit = g_memStack.load(std::memory_order_acquire); could be re-ordered to execute first at runtime?


  • If so, how would I fix that? Could I just change the memory order to std::memory_order_aquery? Would that require another release operation to cooperate with it (I don't think so, because cppreference said std::memory_order_acquire will prevent read and write from reordering before it)?


  • Anything else?


#include <string>
#include <thread>
#include <vector>
#include <cstdlib>
#include <atomic>
#include <cassert>

struct MemUnit

MemUnit *m_next;//next unit
void *m_data;//memory for data
;

void *g_buffernullptr;
std::atomic<MemUnit *> g_memStack;
std::atomic<MemUnit *> g_waitingReclaims;
std::atomic<uint32_t> g_allocatingCounter;

void InitMemPool(size_t poolSize, size_t blockSize);
void UninitMemPool();

MemUnit *StepToTail(MemUnit* listHead);
void Reclaim(MemUnit* listHead, MemUnit* listTail);
void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail);

MemUnit *Allocate()

g_allocatingCounter.fetch_add(1, std::memory_order_relaxed);//Warning: Something wrong with the memory order. It maybe reorder after the next line at runtime.
MemUnit *unit = g_memStack.load(std::memory_order_acquire);
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

MemUnit *pendingList = g_waitingReclaims.exchange(nullptr, std::memory_order_acquire);
const bool canReclaim = g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed) == 1;//this operation can not reorder before exchange operation Just because the 'memory_order_acquire'
//If 'canReclaim' is true, it's ABA problem free. Because there is nobody in 'Allocate' hold same pointer within pending list.
if (canReclaim && pendingList != nullptr)

canReclaim ? Reclaim(pendingList, StepToTail(pendingList)) : GiveBackToWaitings(pendingList, StepToTail(pendingList));

return unit;

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);//this operation can not reorder before 'compare_exchange_weak' Just because the 'memory_order_acquire'
return unit;


void FreeMemUnit(MemUnit* item)

item->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(item->m_next, item, std::memory_order_release, std::memory_order_relaxed));


MemUnit *StepToTail(MemUnit* listHead)

assert(listHead != nullptr);
while (listHead->m_next) listHead = listHead->m_next;
return listHead;


void Reclaim(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_memStack.load(std::memory_order_relaxed);
while (!g_memStack.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_release, std::memory_order_relaxed));


void GiveBackToWaitings(MemUnit* listHead, MemUnit* listTail)

listTail->m_next = g_waitingReclaims.load(std::memory_order_relaxed);
while (!g_waitingReclaims.compare_exchange_weak(listTail->m_next, listHead, std::memory_order_relaxed, std::memory_order_relaxed));
//Yes, it's 'relaxed' memory order when it's success.


void InitMemPool(size_t poolSize, size_t blockSize)

const size_t unitSize = sizeof(MemUnit) + blockSize;
g_buffer = reinterpret_cast<uint8_t *>(std::malloc(unitSize * poolSize));

MemUnit* next = nullptr;
uint8_t* rawBuffer = reinterpret_cast<uint8_t*>(g_buffer);
for (size_t i = 0; i != poolSize; ++i)

MemUnit* pObj = reinterpret_cast<MemUnit *>(rawBuffer);
pObj->m_next = next;
next = pObj;
rawBuffer += unitSize;

g_memStack.store(next, std::memory_order_relaxed);


void UninitMemPool()

assert(g_allocatingCounter.load(std::memory_order_relaxed) == 0);

g_memStack.store(nullptr, std::memory_order_relaxed);
g_waitingReclaims.store(nullptr, std::memory_order_relaxed);
std::free(g_buffer);
g_buffer = nullptr;




void WorkThread()

for (size_t i = 0; i != 128; ++i)

MemUnit *unit = Allocate();
if (unit != nullptr)

//do something use unit.m_data;
FreeMemUnit(unit);




int main()

InitMemPool(128, 1024);

std::vector<std::thread> allThreads;
for (size_t i = 0; i != 8; ++i)

std::thread t(WorkThread);
allThreads.push_back(std::move(t));

for (auto &t : allThreads)

t.join();

UninitMemPool();
return 0;







c++ c++11 lock-free






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 23 hours ago







water











migrated from stackoverflow.com 15 mins ago


This question came from our site for professional and enthusiast programmers.









migrated from stackoverflow.com 15 mins ago


This question came from our site for professional and enthusiast programmers.









  • 1




    $begingroup$
    Please check your initialization of the atomics to be correct. I don't know if it is, but there is usually some very weird stuff going on if done wrong.
    $endgroup$
    – Thomas Lang
    21 hours ago










  • $begingroup$
    @ThomasLang: the 3 atomic<T> variables are all pointer-sized or 32-bit, and have static storage duration. On normal C++ implementations (like x86 gcc or MSVC, or ARM, or whatever), they will be lock-free, and thus zero-initialization of their object representation will give correct behaviour. (As far as C++ language rules, yes, it's a good idea to make sure you init them correctly, but this doesn't explain any weirdness observed on real systems.)
    $endgroup$
    – Peter Cordes
    15 hours ago










  • $begingroup$
    @Peter Cordes: I have completed the code. Yes, i didn't observe anything weird. The program is just a practice and i can't guarantee it works as what i think(Some times it's really hard to find bugs behind lock-free codes). So i came here and wanted to known what others thinking about this(Yes, it's really like a code review).
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    @Cody: nice edit! Typo: aquery -> acquire (I don't have 2k rep on this .SE to fix it myself.)
    $endgroup$
    – Peter Cordes
    11 mins ago












  • 1




    $begingroup$
    Please check your initialization of the atomics to be correct. I don't know if it is, but there is usually some very weird stuff going on if done wrong.
    $endgroup$
    – Thomas Lang
    21 hours ago










  • $begingroup$
    @ThomasLang: the 3 atomic<T> variables are all pointer-sized or 32-bit, and have static storage duration. On normal C++ implementations (like x86 gcc or MSVC, or ARM, or whatever), they will be lock-free, and thus zero-initialization of their object representation will give correct behaviour. (As far as C++ language rules, yes, it's a good idea to make sure you init them correctly, but this doesn't explain any weirdness observed on real systems.)
    $endgroup$
    – Peter Cordes
    15 hours ago










  • $begingroup$
    @Peter Cordes: I have completed the code. Yes, i didn't observe anything weird. The program is just a practice and i can't guarantee it works as what i think(Some times it's really hard to find bugs behind lock-free codes). So i came here and wanted to known what others thinking about this(Yes, it's really like a code review).
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    @Cody: nice edit! Typo: aquery -> acquire (I don't have 2k rep on this .SE to fix it myself.)
    $endgroup$
    – Peter Cordes
    11 mins ago







1




1




$begingroup$
Please check your initialization of the atomics to be correct. I don't know if it is, but there is usually some very weird stuff going on if done wrong.
$endgroup$
– Thomas Lang
21 hours ago




$begingroup$
Please check your initialization of the atomics to be correct. I don't know if it is, but there is usually some very weird stuff going on if done wrong.
$endgroup$
– Thomas Lang
21 hours ago












$begingroup$
@ThomasLang: the 3 atomic<T> variables are all pointer-sized or 32-bit, and have static storage duration. On normal C++ implementations (like x86 gcc or MSVC, or ARM, or whatever), they will be lock-free, and thus zero-initialization of their object representation will give correct behaviour. (As far as C++ language rules, yes, it's a good idea to make sure you init them correctly, but this doesn't explain any weirdness observed on real systems.)
$endgroup$
– Peter Cordes
15 hours ago




$begingroup$
@ThomasLang: the 3 atomic<T> variables are all pointer-sized or 32-bit, and have static storage duration. On normal C++ implementations (like x86 gcc or MSVC, or ARM, or whatever), they will be lock-free, and thus zero-initialization of their object representation will give correct behaviour. (As far as C++ language rules, yes, it's a good idea to make sure you init them correctly, but this doesn't explain any weirdness observed on real systems.)
$endgroup$
– Peter Cordes
15 hours ago












$begingroup$
@Peter Cordes: I have completed the code. Yes, i didn't observe anything weird. The program is just a practice and i can't guarantee it works as what i think(Some times it's really hard to find bugs behind lock-free codes). So i came here and wanted to known what others thinking about this(Yes, it's really like a code review).
$endgroup$
– water
2 hours ago




$begingroup$
@Peter Cordes: I have completed the code. Yes, i didn't observe anything weird. The program is just a practice and i can't guarantee it works as what i think(Some times it's really hard to find bugs behind lock-free codes). So i came here and wanted to known what others thinking about this(Yes, it's really like a code review).
$endgroup$
– water
2 hours ago












$begingroup$
@Cody: nice edit! Typo: aquery -> acquire (I don't have 2k rep on this .SE to fix it myself.)
$endgroup$
– Peter Cordes
11 mins ago




$begingroup$
@Cody: nice edit! Typo: aquery -> acquire (I don't have 2k rep on this .SE to fix it myself.)
$endgroup$
– Peter Cordes
11 mins ago










1 Answer
1






active

oldest

votes


















1












$begingroup$


'g_memStack' is a stack that contains memory unit. We can allocate
memory unit from it




There is not a single line of code allocating MemUnit




This a thread safe and lock-free memory pool program




Unfortunately this is not true. Assume two threads are executing Allocate on an empty stack in a fully interleaved manner.



g_allocatingCounter.fetch_add(1, std::memory_order_relaxed); //T1 : 1, T2 : 2
MemUnit *unit = g_memStack.load(std::memory_order_acquire); //T1 : nullptr, T2 : nullptr
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

//let's assume its fine here
return unit; // T1 : something

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);
return unit; //T2 : nullptr


They reach if (g_allocatingCounter.load(std::memory_order_relaxed) == 1) with the variable unit being null. The condition is true for one thread but not the other.



The thread for which the condition is false will return nullptr.






share|improve this answer









$endgroup$












  • $begingroup$
    Thanks for your reply. Yes, the function is allowed to return nullptr.
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
    $endgroup$
    – Peter Cordes
    12 mins ago











Your Answer





StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
);
);
, "mathjax-editing");

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "196"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f216762%2fcreating-a-lock-free-memory-pool-using-c11-features%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown
























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1












$begingroup$


'g_memStack' is a stack that contains memory unit. We can allocate
memory unit from it




There is not a single line of code allocating MemUnit




This a thread safe and lock-free memory pool program




Unfortunately this is not true. Assume two threads are executing Allocate on an empty stack in a fully interleaved manner.



g_allocatingCounter.fetch_add(1, std::memory_order_relaxed); //T1 : 1, T2 : 2
MemUnit *unit = g_memStack.load(std::memory_order_acquire); //T1 : nullptr, T2 : nullptr
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

//let's assume its fine here
return unit; // T1 : something

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);
return unit; //T2 : nullptr


They reach if (g_allocatingCounter.load(std::memory_order_relaxed) == 1) with the variable unit being null. The condition is true for one thread but not the other.



The thread for which the condition is false will return nullptr.






share|improve this answer









$endgroup$












  • $begingroup$
    Thanks for your reply. Yes, the function is allowed to return nullptr.
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
    $endgroup$
    – Peter Cordes
    12 mins ago















1












$begingroup$


'g_memStack' is a stack that contains memory unit. We can allocate
memory unit from it




There is not a single line of code allocating MemUnit




This a thread safe and lock-free memory pool program




Unfortunately this is not true. Assume two threads are executing Allocate on an empty stack in a fully interleaved manner.



g_allocatingCounter.fetch_add(1, std::memory_order_relaxed); //T1 : 1, T2 : 2
MemUnit *unit = g_memStack.load(std::memory_order_acquire); //T1 : nullptr, T2 : nullptr
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

//let's assume its fine here
return unit; // T1 : something

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);
return unit; //T2 : nullptr


They reach if (g_allocatingCounter.load(std::memory_order_relaxed) == 1) with the variable unit being null. The condition is true for one thread but not the other.



The thread for which the condition is false will return nullptr.






share|improve this answer









$endgroup$












  • $begingroup$
    Thanks for your reply. Yes, the function is allowed to return nullptr.
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
    $endgroup$
    – Peter Cordes
    12 mins ago













1












1








1





$begingroup$


'g_memStack' is a stack that contains memory unit. We can allocate
memory unit from it




There is not a single line of code allocating MemUnit




This a thread safe and lock-free memory pool program




Unfortunately this is not true. Assume two threads are executing Allocate on an empty stack in a fully interleaved manner.



g_allocatingCounter.fetch_add(1, std::memory_order_relaxed); //T1 : 1, T2 : 2
MemUnit *unit = g_memStack.load(std::memory_order_acquire); //T1 : nullptr, T2 : nullptr
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

//let's assume its fine here
return unit; // T1 : something

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);
return unit; //T2 : nullptr


They reach if (g_allocatingCounter.load(std::memory_order_relaxed) == 1) with the variable unit being null. The condition is true for one thread but not the other.



The thread for which the condition is false will return nullptr.






share|improve this answer









$endgroup$




'g_memStack' is a stack that contains memory unit. We can allocate
memory unit from it




There is not a single line of code allocating MemUnit




This a thread safe and lock-free memory pool program




Unfortunately this is not true. Assume two threads are executing Allocate on an empty stack in a fully interleaved manner.



g_allocatingCounter.fetch_add(1, std::memory_order_relaxed); //T1 : 1, T2 : 2
MemUnit *unit = g_memStack.load(std::memory_order_acquire); //T1 : nullptr, T2 : nullptr
while (unit != nullptr && !g_memStack.compare_exchange_weak(unit, unit->m_next, std::memory_order_acquire, std::memory_order_acquire));
if (g_allocatingCounter.load(std::memory_order_relaxed) == 1)

//let's assume its fine here
return unit; // T1 : something

g_allocatingCounter.fetch_sub(1, std::memory_order_relaxed);
return unit; //T2 : nullptr


They reach if (g_allocatingCounter.load(std::memory_order_relaxed) == 1) with the variable unit being null. The condition is true for one thread but not the other.



The thread for which the condition is false will return nullptr.







share|improve this answer












share|improve this answer



share|improve this answer










answered 19 hours ago









UmNyobeUmNyobe

17910




17910











  • $begingroup$
    Thanks for your reply. Yes, the function is allowed to return nullptr.
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
    $endgroup$
    – Peter Cordes
    12 mins ago
















  • $begingroup$
    Thanks for your reply. Yes, the function is allowed to return nullptr.
    $endgroup$
    – water
    2 hours ago










  • $begingroup$
    For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
    $endgroup$
    – Peter Cordes
    12 mins ago















$begingroup$
Thanks for your reply. Yes, the function is allowed to return nullptr.
$endgroup$
– water
2 hours ago




$begingroup$
Thanks for your reply. Yes, the function is allowed to return nullptr.
$endgroup$
– water
2 hours ago












$begingroup$
For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
$endgroup$
– Peter Cordes
12 mins ago




$begingroup$
For future readers: this was posted as an answer to the original question, before migration from Stack Overflow. That's why it doesn't look like a code review.
$endgroup$
– Peter Cordes
12 mins ago

















draft saved

draft discarded
















































Thanks for contributing an answer to Code Review Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

Use MathJax to format equations. MathJax reference.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f216762%2fcreating-a-lock-free-memory-pool-using-c11-features%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

名間水力發電廠 目录 沿革 設施 鄰近設施 註釋 外部連結 导航菜单23°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.7113923°50′10″N 120°42′41″E / 23.83611°N 120.71139°E / 23.83611; 120.71139計畫概要原始内容臺灣第一座BOT 模式開發的水力發電廠-名間水力電廠名間水力發電廠 水利署首件BOT案原始内容《小檔案》名間電廠 首座BOT水力發電廠原始内容名間電廠BOT - 經濟部水利署中區水資源局

Prove that NP is closed under karp reduction?Space(n) not closed under Karp reductions - what about NTime(n)?Class P is closed under rotation?Prove or disprove that $NL$ is closed under polynomial many-one reductions$mathbfNC_2$ is closed under log-space reductionOn Karp reductionwhen can I know if a class (complexity) is closed under reduction (cook/karp)Check if class $PSPACE$ is closed under polyonomially space reductionIs NPSPACE also closed under polynomial-time reduction and under log-space reduction?Prove PSPACE is closed under complement?Prove PSPACE is closed under union?

Is my guitar’s action too high? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)Strings too stiff on a recently purchased acoustic guitar | Cort AD880CEIs the action of my guitar really high?Μy little finger is too weak to play guitarWith guitar, how long should I give my fingers to strengthen / callous?When playing a fret the guitar sounds mutedPlaying (Barre) chords up the guitar neckI think my guitar strings are wound too tight and I can't play barre chordsF barre chord on an SG guitarHow to find to the right strings of a barre chord by feel?High action on higher fret on my steel acoustic guitar