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












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_buffer{nullptr};
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 6 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
    2 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_buffer{nullptr};
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 6 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
    2 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_buffer{nullptr};
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_buffer{nullptr};
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 22 hours ago







water











migrated from stackoverflow.com 6 mins ago


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









migrated from stackoverflow.com 6 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
    2 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
    2 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
2 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
2 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
    3 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
    3 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
    3 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
    3 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
    3 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
3 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
3 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

Сан-Квентин

8-я гвардейская общевойсковая армия

Алькесар