On 11/13/2014 09:34 PM, Iain Sandoe wrote: >> Um, surely not LOCK_SIZE, but CACHELINE_SIZE. It's the granularity of the >> target region that's at issue, not the size of the lock itself. > > The algorithm I've used is intentionally different from the pthreads-based > posix one...
All that would be fine if ... > +/* The granularity at which locks are applied when n > CACHLINE_SIZE. > + We follow the posix pthreads implementation here. */ > +#ifndef WATCH_SIZE > +# define WATCH_SIZE CACHLINE_SIZE > +#endif ... you hadn't just said right here that the granularity at which you want to lock is WATCH_SIZE, > +#define LOCK_SIZE sizeof(LOCK_TYPE) > +#define NLOCKS (PAGE_SIZE / LOCK_SIZE) > +/* An array of locks, that should fill one physical page. */ > +static LOCK_TYPE locks[NLOCKS] __attribute__((aligned(PAGE_SIZE))); ... but then go and use LOCK_SIZE instead. r~
