On 04/04/14 17:01, James Starkey wrote: > I know of many very smart people who have tried to lick this problem > without success. Iy feels like there should be a solution, but avoiding an > ABA problem on release seems insurmountable.
From what I've read the only good solution for ABA problem is restartable critical section. Unfortunately it has one disadvantage - not supported by most of OS. And if I can easily patch glibc and rebuild it on my own box suggesting all FB users to do it is hardly realistic (even forgetting about windows users). But even with restartable critical sections we need atomic ops to allocate / free block. > 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. > Thread specific sub-pools does make fragmentation slightly worse. And, of > course, each thread specific sub-pool needs to be flushed back to the main > pool. > > I'm not suggesting that this is a priority or even a good fit for Firebird, > but just that the assumption of a no-lock memory pool is probably unsound. > yes > > > ------------------------------------------------------------------------------ > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
