RE: [boost] Re: Re: [Thread] Perennial rw_mutex question
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. 0.000000000000002 lira, Matt Hurd IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"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). 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 member functions ---------------- read_lock try_read_lock timed_read_lock write_lock try_write_lock timed_write_lock enumeration constants --------------------- sp_writer_priority sp_reader_priority sp_alternating_many_reads sp_alternating_single_read Mike
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.
participants (5)
-
Hurd, Matthew -
Matt Hurd -
Michael Glassford