On 14 Nov 2014, at 08:25, Richard Henderson wrote: > On 11/14/2014 09:12 AM, Iain Sandoe wrote: >> my locks are only 4 bytes [whereas they are >> rounded-up-to-n-cachlines(sizeof(pthreads mutext)) for the posix >> implementation]. >> The items that they are locking are of arbitrary size (at least up to one >> page). >> >> hmmm .. there's something I'm not following about what you are seeing as a >> problem here. >> >> In the posix implementation the granularity calculation is also used to >> round up the space allocated in the locks table for each pthreads mutex >> (i.e. it has two uses, AFAICT). > > No, there's only one use: How large an area is *protected* by the lock. > > Since we need to protect one page of these areas, we need NLOCKS = PAGE_SIZE / > WATCH_SIZE locks, which are then allocated in an array. We do not care how > large that array is. > > So if you'd like to differ from the posix implementation in protecting > 4 bytes at a time, rather than one cacheline at a time, then just change > WATCH_SIZE to 4. The fact that WATCH_SIZE happens to equal to the lock size > is > simply a coincidence.
Indeed (the use to round up the space allocated for the mutex also happens to be another co-incidence) However, my intention is to have a variable-sized area protected by each locks. The nummber of locks allocated exceeds (page-size/watch-size) [unless watch-sizes was reduced to 4bytes, of course] Only when the size of the area to be protected exceeds one cache-line do I split it up into cache-line-sized chunks. I happened to allocate one-page-worth of locks (as a somewhat arbitrary choice in the absence of metrics to guide otherwise) - which is another source of co-incidence. Perhaps some re-naming of things would help, or do you think that a scheme to lock variable-sized chunks cannot work? Iain
