Re: [boost] Re: Re: Re: [Thread] Perennial rw_mutex question

From: Matt Hurd (matt_at_[hidden])
Date: 2004-05-05 07:34:43

Michael Glassford wrote:

>"Hurd, Matthew" <hurdm_at_[hidden]> wrote in message
>news:BA1220310B07EC4A8E321B451E07AF47766CCC_at_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.