mempool usage about mlib HOT 6 CLOSED

You can qualify the mempool with M_THREAD_ATTR (or __thread or _Thread_local) to create mempool variables unique for each thread like this:

extern int rand_get(void);
extern int g_result;

LIST_DEF(list_uint, unsigned int, (MEMPOOL( list_mpool), MEMPOOL_LINKAGE(M_THREAD_ATTR )))

void test_list (size_t n)
{
  M_LET(a1, a2, LIST_OPLIST(list_uint)) {
    for(size_t i = 0; i < n; i++) {
      list_uint_push_back(a1, rand_get() );
      list_uint_push_back(a2, rand_get() );
    }
    unsigned int s = 0;
    list_uint_it_t it1, it2;
    for(list_uint_it(it1, a1), list_uint_it(it2,a2); !list_uint_end_p(it1); list_uint_next(it1), list_uint_next(it2)) {
      s += *list_uint_cref(it1) * *list_uint_cref(it2);
    }
    g_result = s;
  }
}

void *thread(void*)
{
  list_uint_mempool_init(list_mpool);
  ...
  test_list();
  ...
  list_uint_mempool_clear(list_mpool);
}

list_mpool will be a different variable in each thread.
I haven't tested this solution myself, but I don't see why it could not work. The drawbacks may be:

• You will have to initialize the mempool for each thread
• If nodes can be seen from other threads, you need to destroy all mempools at the same time.
• you have more memory consumption.
• the lists are not lock free, but local to a thread.

from mlib.

Ok, now it is clear how to bind a mempool to the context of a thread.
The other question, indeed I was not clear, is if I can use a mempool (specialized for a tuple) to feed the allocation requests of a M_LET macro willing to instantiate some of such tuples.

from mlib.

I am not sure if I understand the question well.
The M_LET macro allocates the temporary variables on the stack, letting the underlying type of the variable decides with its initialization method if it needs some allocation. A tuple won't perform any allocation on its own.
So you cannot use a mempool specialized for a tuple to feed M_LET as such mempool doesn't exist.

from mlib.

Ok, I didn't know M_LET macro uses the stack: I thought it used malloc/free (it could, right?). My idea was to use the heap but recycling tuples from a mempool: could it be faster than using the stack?

from mlib.

M_LET allocate the variable on the stack itself but it is not recursive. For example in the example above a1 and a2 structures (the lists) are allocated on the stack, but the nodes of theses lists are allocated using mempool.

I doubt a mempool used for allocation of tuples can be faster than the stack allocation of tuple (There is intrinsically more work to do in the case of mempool compared to the stack).

from mlib.

Ok, it was a desperate attempt to optimize the code. The use of an advanced allocator like tcmalloc helped a bit without much effort.
Thanks anyway.

from mlib.