I am new to this list, so I apologize if this has already been discussed.
boost_1_53_0/libs/atomic/src/lockpool.cpp contains: static lockpool::lock_type lock_pool_[41]; On most systems, I would expect that lock_type becomes atomic<bool> v_;
I therefore seems to me that we are packing a large number of commonly used locks into sequential memory and therefore increasing the risk of false sharing due to cache line sharing. At the same time, I expect that the 41 lock instances will be used frequently and as such it seems to make sense to align the array to a VM page boundary (to get only a single hot VM page).
Has alignment/padding been considered for the lock_pool implementation? If so what are the reasons for its dismissal?
good observation. the spinlock pool has a lot of false sharing ... will add some padding to the lockpool ... aligning to a vm page also makes sense, though i'll have to see, if there is a non-intrusive way to achieve this ... cheers, tim