[boost] atomic lockpool and alignment

[Jesper Storm Bache]

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?

Thanks,
Jesper Storm Bache

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Tim Blechmann]

> 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