thread-safe dict->Exp_pool neeed

[linas]

The dict-atomese dictionary adds new expressions to the dict constantly. These are obtained from equivalent Atomese expressions. This runs highly parallel, and so I use a mutex lock to protect dict->Exp_pool, specifically, to protect calls to pool_vec()

Indirect evidence indicates that there is severe lock contention as a result. The evidence is this: if I use the LG any dict, I can run 64 threads full speed, no problem. If I use the atomese dict, then the system maxes out with 6-8 threads for the first half-hour, then later, at 8-12 threads after an hour, 16-21 after five hours, and 24-30 after an overnight run. Hypothesize that this is because the dict starts out empty, and is being filled very very rapidly, at first, resulting in lock contention, and then, later, once the dict is more full, I get "cache hits" into the dict (the word is already in there), for which no calls to pool_alloc() are needed. I'm pretty sure this is what is happening.

I have several ideas:

• Move the mutex from dict-atomspace to pool_alloc() (but only for this one pool). That is, move the mutex closer to the thing that actually needs to be protected. I suspect this will not help much. probably not help at all: there's very little in between the current mutex and the pool.

• Create a per-thread local cache: so, in each thread, do a pool_alloc_vec(1000) under a lock, but then do individual pool_alloc() out of this, lock-free. Unclear if there is some good way of doing this. I want to avoid complex solutions.

• Do NOT use the pool allocator for the atomese dict->Exp_pool, use the ordinary malloc() impl. This should run fast, since malloc uses per-thread arenas.

• Create a per-thread dict->Exp_pool. This is "reasonable" because the LG dict only ever grows (at this time. Perhaps someday it will need to shrink.) However, there are tricky questions: what to do on thread exit? Cleanup the pool? What's already in the dict needs to stay in the dict, on thread exit. Later on, what if the dict is deleted? then what? What happens to the dict->Exp_pool?

Any suggestions? I'm leaning to just doing ordinary malloc for the dict->Exp_pool as this seems like the simplest thing to code up. Everything else feels much more complicated.

[linas]

Yeah, this is not the problem. It's a problem, but there's more to it than just that. Closing

[linas]

Explored in my branch lockfree-hack & clean version in locked-expressions and makes no noticable difference in performance. This will require profiling work to find out what is going on.