Michael Glassford wrote:
"Hurd, Matthew" <hurdm@sig.com> wrote in message news:BA1220310B07EC4A8E321B451E07AF47766CCC@msgbal501.ds.susq.com...
On Behalf Of Michael Glassford * Rename to improve consistency and eliminate abbreviations: Use "read" and "write" instead of "shared" and "exclusive".
Just a quick note from the bike shop. I've always had an issue with rw/read/write as this is a common use case rather than
shared/exclusive
which is the real deal.
Going along these lines I think rw_mutex is a bad name, though I
grant
it is commonly understood.
The oxymoron shareable_mutex or something other shorter name would
make
me happier.
I agree that shared/exclusive are more general terms than read/write. I stuck with read/write for now for several not very weighty reasons: 1) AFAIK, that's the common, accepted terminology for this type of mutex; 2) that's the terminology most of the library was already using; 3) some names didn't seem to convert conveniently to the shared/exclusive terminolgy; 4) using read/write seems to result in shorter names. I'm not stuck on a particular terminology, however; what I care about is that it's consistent (not read/write in some places and shared/exclusive in others, which is how it was before).
I especially worry that anything but read and write will confuse the majority as per 1.
In other words, I'm open to renaming suggestions. Here's a list of currently used names that any naming proposal would need to address:
classes ------- read_write_mutex try_read_write_mutex timed_read_write_mutex scoped_read_write_lock scoped_try_read_write_lock scoped_timed_read_write_lock
read_write -> shareable
member functions ---------------- read_lock try_read_lock timed_read_lock write_lock try_write_lock timed_write_lock
read -> shared write -> exclusive
enumeration constants --------------------- sp_writer_priority
sp_priority_exclusive
sp_reader_priority
sp_priority_shared
sp_alternating_many_reads
sp_priority_alternating_shared_bias
sp_alternating_single_read
sp_priority_alternating
Mike
For sure, read/write is the common case. However, try a little thought experiment in how confusing it becomes when you allow many writers but only one reader... Struggling to think of a practical example of this though, but computing aggregates from or otherwise dealing with consistent views of a data set would qualify I guess. That is, data structure supports many writers but you need to freeze to query or aggregate. Thinking about taking read locks to write and write locks to read makes my head spin ;-) Regards, matt PS: Great work on moving this forward. Thank you for your efforts.