
There was a long discussion about shared_mutex et al, and that was great. I don't want to start it all over again, but I was just wondering about the name: - I agree that 'reader writer', while known, might not be the best basis for a name - 'shared' is part of the answer but - aren't the terms 'shared' and 'mutual exclusion' (as in 'mutex'), well, mutually exclusive? ie somewhat contradicting? also, maybe 'shareable' is better than 'shared'? (other than an argument over whether it should have an 'e' stuck in the middle there or not) so how about: 'sharable_exclusion' (still sounds contradictory?) (sharex?) 'access_controller' - doesn't use known terminology, but is closer to what is really going on - it controls access to a resource. or 'shareable_access'? or ? shared_or_exclusive_access is probably the 'truest' description (and closest to reader_writer, as it does list both 'sides of the coin'), but a bit wordy... Tony

Gottlob Frege wrote:
There was a long discussion about shared_mutex et al, and that was great. I don't want to start it all over again, but I was just wondering about the name:
- I agree that 'reader writer', while known, might not be the best basis for a name
Well, personally I like read_write_mutex (rw_mutex or any variation of it). Yes, it is well known, widely used and is an established term. Seeing it in a piece of code I will know what's going on from the first sight, while with shared_mutex (or something of that sort) I'll have to dig out what was really meant here. That's my HO.

On Sep 25, 2007, at 11:57 AM, Gottlob Frege wrote:
There was a long discussion about shared_mutex et al, and that was great. I don't want to start it all over again, but I was just wondering about the name:
- I agree that 'reader writer', while known, might not be the best basis for a name - 'shared' is part of the answer
but
- aren't the terms 'shared' and 'mutual exclusion' (as in 'mutex'), well, mutually exclusive? ie somewhat contradicting?
also, maybe 'shareable' is better than 'shared'? (other than an argument over whether it should have an 'e' stuck in the middle there or not)
so how about:
'sharable_exclusion' (still sounds contradictory?) (sharex?)
'access_controller' - doesn't use known terminology, but is closer to what is really going on - it controls access to a resource.
or
'shareable_access'?
or ?
shared_or_exclusive_access is probably the 'truest' description (and closest to reader_writer, as it does list both 'sides of the coin'), but a bit wordy...
I think you make some valid points and good suggestions. But I would like to see your suggestions discussed within the context of all of the mutex and lock names. My current list is: mutex recursive_mutex timed_mutex recursive_timed_mutex scoped_lock unique_lock shared_mutex shared_lock upgrade_mutex upgrade_lock Reference: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html It might also be good to at the same time consider all of the member names of upgrade_mutex as a consistent naming scheme helps keep everything straight: class upgrade_mutex { public: upgrade_mutex(); ~upgrade_mutex(); upgrade_mutex(const upgrade_mutex&) = delete; upgrade_mutex& operator=(const upgrade_mutex&) = delete; // Unique ownership void lock(); bool try_lock(); bool timed_lock(nanoseconds rel_time); void unlock(); // Shared ownership void lock_shared(); bool try_lock_shared(); bool timed_lock_shared(nanoseconds rel_time); void unlock_shared(); // Upgrade ownership void lock_upgrade(); bool try_lock_upgrade(); bool timed_lock_upgrade(nanoseconds rel_time); void unlock_upgrade(); // Shared <-> Unique bool try_unlock_shared_and_lock(); bool timed_unlock_shared_and_lock(nanoseconds rel_time); void unlock_and_lock_shared(); // Shared <-> Upgrade bool try_unlock_shared_and_lock_upgrade(); bool timed_unlock_shared_and_lock_upgrade(nanoseconds rel_time); void unlock_upgrade_and_lock_shared(); // Upgrade <-> Unique void unlock_upgrade_and_lock(); // This conversion is unique to upgrade ownership bool try_unlock_upgrade_and_lock(); bool timed_unlock_upgrade_and_lock(nanoseconds rel_time); void unlock_and_lock_upgrade(); }; I'm not married to any of the names, and have sympathy for the "existing use" argument for rw_mutex. But that still doesn't help with the upgrade_mutex name. I agree that good names are important. And I would like to see suggestions within the context of the whole package (e.g. especially the member ownership conversion functions). -Howard
participants (3)
-
Andrey Semashev
-
Gottlob Frege
-
Howard Hinnant