On 04/04/14 17:43, Dimitry Sibiryakov wrote: > 04.04.2014 15:37, Alex Peshkoff wrote: >> On 04/04/14 17:01, James Starkey wrote: >>> An alternate solution that is close is thread specific sub-pools, which is >>> nice because a thread specific sub-pool doesn't even need interlocked >>> instructions. It does require a fetch of thread specific data on every >>> allocate and release, but some platforms dedicate a register to point to >>> thread specific data, making the op essentially free. >> Unfortunately on a lot of platforms which seem to provide such support >> it does not work in dynamic libraries. Our engine is dynamic library... >> To be precise even use of traditional TLS calls is relatively fast - >> TLS_get requires about 10-15 machine instructions to complete which much >> less than single atomic op, not to say about locking something. > With thread-specific pools isn't it impossible to allocate object in one > thread and > then release in other?.. >
That depends upon implementation. With our current implementation it's possible, but pools can't be no-lock in that case. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
