TLRW-ByteLock: return of the read-write lock by myself and Nir Shavit will appear in Transact 2009. (Slides).
Permanent link to this entry
Have you considered the possibility of grouping bytes in byte-array (in byte-lock) based not on lock object, but instead based on slotted thread id. I.e. current layout:
char byte_array ;
byte_lock g_locks [LOCK_COUNT];
What I am talking about is:
char unused ; // probably still required
char byte_array [LOCK_COUNT];
byte_lock_part1 g_locks1 [LOCK_COUNT];
byte_lock_part2 g_locks2 ; // actually in this layout 48 can be replaced with arbitrary number
Have you rejected such layout? Or just did not consider? I think provided low write rate such layout may provide some benefits, because readers do not contend for cache-lines.
on April 02, 2009 at 08:49 PM EDT
Dmitriy, you will still have contention over the byte-array across the different readers. I don't think reader-writer contention was a primary focus since the lock is still targeting read-mostly workloads (of course, writer starvation is dealt with by the algorithm itself).
Even if it was, the reader-writer contention will still exist when using the CAS-less variant of the slotted write lock.
Samy Al Bahra
on August 08, 2010 at 01:44 PM EDT
Dave is a senior research scientist in the Scalable Synchronization Research Group within Oracle Labs : Google Scholar.