benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_documentation/tests/vault/mem/local-mem-pool-test.cpp

138 lines
2.9 KiB
C++
Raw Normal View History

BufferProvider: start planning for the memory handling part As staring point, it is clear that the `BufferStore` side of the implementation will rely on a similar structure with a thread-local base service — which in this case will have to maintain a small pool of recently used buffer allocations...
2026-04-21 23:30:35 +02:00
/*
LocalMemPool(Test) - verify low-level handling of buffer blocks in a local pool
Copyright (C)
2026, Hermann Vosseler <Ichthyostega@web.de>
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
* *****************************************************************/
/** @file local-mem-pool-test.cpp
** unit test \ref LocalMemPool_test
*/
#include "test/run.hpp"
#include "test/test-helper.hpp"
//#include "vault/mem/engine-buffer-metadata.hpp"
#include "vault/mem/local-mem-pool.hpp"
//#include "lib/depend-inject.hpp"
//#include "lib/thread.hpp"
//#include "lib/error.hpp"
//using std::this_thread::yield;
//using lib::Thread;
namespace vault {
namespace mem {
namespace test {
// using LERR_(LOGIC);
// using LERR_(LIFECYCLE);
namespace { // Test helper
BufferProvider: decision to use a free-standing pool with lock-free queue After several fruitless attempts, I have decided now to settle for self-contained ''memory pool'' component, that can be operated **thread-locally** and employs a **lock-free** message queue for the allotment of memory. Seemingly the question of how this relates to `BufferMetadata` must remain unresolved for the time being, until the entire buffer memory subsystem is available for empirical investigation.
2026-04-24 17:36:44 +02:00
inline constexpr Buff*
fake_Buffer(size_t id)
{
return reinterpret_cast<Buff*> (id);
}
Buff* const MEM1 = fake_Buffer(1);
Buff* const MEM2 = fake_Buffer(2);
Buff* const MEM3 = fake_Buffer(3);
const size_t SIZ10{10};
const size_t SIZ20{20};
const size_t SIZ30{30};
BufferProvider: start planning for the memory handling part As staring point, it is clear that the `BufferStore` side of the implementation will rely on a similar structure with a thread-local base service — which in this case will have to maintain a small pool of recently used buffer allocations...
2026-04-21 23:30:35 +02:00
}
/**********************************************************************//**
* @test verify handling of prospective buffer allocations in a local pool.
*/
class LocalMemPool_test : public Test
{
virtual void
run (Arg)
{
seedRand();
BufferProvider: decision to use a free-standing pool with lock-free queue After several fruitless attempts, I have decided now to settle for self-contained ''memory pool'' component, that can be operated **thread-locally** and employs a **lock-free** message queue for the allotment of memory. Seemingly the question of how this relates to `BufferMetadata` must remain unresolved for the time being, until the entire buffer memory subsystem is available for empirical investigation.
2026-04-24 17:36:44 +02:00
simpleUse();
verify_matchAlloc();
verify_selectAlloc();
verify_pruneAlloc();
BufferProvider: start planning for the memory handling part As staring point, it is clear that the `BufferStore` side of the implementation will rely on a similar structure with a thread-local base service — which in this case will have to maintain a small pool of recently used buffer allocations...
2026-04-21 23:30:35 +02:00
}
BufferProvider: decision to use a free-standing pool with lock-free queue After several fruitless attempts, I have decided now to settle for self-contained ''memory pool'' component, that can be operated **thread-locally** and employs a **lock-free** message queue for the allotment of memory. Seemingly the question of how this relates to `BufferMetadata` must remain unresolved for the time being, until the entire buffer memory subsystem is available for empirical investigation.
2026-04-24 17:36:44 +02:00
/** @test show how to place an allocation into the pool */
void
simpleUse()
{
LocalMemPool pool;
pool.add (MEM1, SIZ20);
CHECK (pool.canServe(SIZ20));
CHECK (pool.canServe(SIZ10));
auto [mem,siz] = pool.retrieve (SIZ10);
CHECK (MEM1 == mem);
CHECK (SIZ20 == siz);
CHECK (not pool.canServe(SIZ10));
pool.reAdd (MEM1);
CHECK (pool.canServe(SIZ20));
}
/** @test
*/
void
verify_matchAlloc()
{
LocalMemPool pool;
CHECK (watch(pool).isEmpty());
pool.add (MEM1, SIZ10);
CHECK (watch(pool).cnt(SIZ10) == 1);
}
/** @test
*/
BufferProvider: start planning for the memory handling part As staring point, it is clear that the `BufferStore` side of the implementation will rely on a similar structure with a thread-local base service — which in this case will have to maintain a small pool of recently used buffer allocations...
2026-04-21 23:30:35 +02:00
void
BufferProvider: decision to use a free-standing pool with lock-free queue After several fruitless attempts, I have decided now to settle for self-contained ''memory pool'' component, that can be operated **thread-locally** and employs a **lock-free** message queue for the allotment of memory. Seemingly the question of how this relates to `BufferMetadata` must remain unresolved for the time being, until the entire buffer memory subsystem is available for empirical investigation.
2026-04-24 17:36:44 +02:00
verify_selectAlloc()
BufferProvider: start planning for the memory handling part As staring point, it is clear that the `BufferStore` side of the implementation will rely on a similar structure with a thread-local base service — which in this case will have to maintain a small pool of recently used buffer allocations...
2026-04-21 23:30:35 +02:00
{
}
/** @test
*/
void
BufferProvider: decision to use a free-standing pool with lock-free queue After several fruitless attempts, I have decided now to settle for self-contained ''memory pool'' component, that can be operated **thread-locally** and employs a **lock-free** message queue for the allotment of memory. Seemingly the question of how this relates to `BufferMetadata` must remain unresolved for the time being, until the entire buffer memory subsystem is available for empirical investigation.
2026-04-24 17:36:44 +02:00
verify_pruneAlloc()
BufferProvider: start planning for the memory handling part As staring point, it is clear that the `BufferStore` side of the implementation will rely on a similar structure with a thread-local base service — which in this case will have to maintain a small pool of recently used buffer allocations...
2026-04-21 23:30:35 +02:00
{
}
};
/** Register this test class... */
LAUNCHER (LocalMemPool_test, "unit engine");
}}} // namespace vault::mem::test
Reference in a new issue Copy permalink