Re: Dynamically allocated locks

[Matt Thomas <matt%3am-software.com@localhost>]

> > Other than that its fine.  I can see not crossing a cacheline  
> > boundary,
> > but only 1 / cacheline is just wrong.
>
> It really does matter on MP systems. If you were to take a machine  
> and have
> all CPUs doing nothing but modifying operations on data within a  
> single
> cache line, then in the best case the machine would in effect be  
> single
> threaded: it would do no better than a single CPU system. In the  
> worst case
> it could be a lot slower due to (for example) costly writebacks to  
> main
> memory.

I understand that but in reality we are only talking about a handful of
lock per cacheline.  if the system has a few looks, this would be bad.
but as we go to finer grained locked, the chances of this being a  
problem
drop dramatically.  For high contention locks (like global lock), one  
per
cache line makes sense.  for low contention locks (like a socket lock),
multiple per cacheline makes sense.

maybe two pools, one for each type?