That's not the point at all. Having a per-thread pool means synchronization-free alloc.

What happens with the object afterwards is not relevant.

But objects are passed around between threads and another thread might want to free it?

Then it goes to the freeing thread memory pool. Thread-aware mallocs know this and have clever balancing mechanisms for situations like producer-consumer, where one thread allocs a lot and another frees a lot.

Edit: wrong, I re-checked. The solution to this is that marking an object as free is lock-free. The freed objects do not immediately change thread pools.