Howard Hinnant wrote:
On Jul 12, 2004, at 11:28 AM, Peter Dimov wrote:
[...]
If we expose either a Mutex* or a Mutex&, and we standardize a public Mutex interface (with lock(), unlock(), etc.), then we are saying that one can call functions on the pointer or reference returned by mutex(). And now that I write that sentence my skin is beginning to crawl. ;-)
This is what 'class mutex' looks like in my original message: class mutex // DefaultConstructible { private: void lock(); bool try_lock(); bool timed_lock( xtime xt ); void unlock(); }; IOW, the function names are standardized, but they aren't public. The intent is to allow users to write a mutex class M that can be used with std::tr2::lock<M>. As a mutex doesn't have a public interface, the mutex() accessor cannot be used to manipulate a lock's associated mutex. It is, of course, possible to make this interface public, but I haven't proposed that. ;-) [...]
Brainstorming:
template <class Mutex> bool operator==(const scoped_lock<Mutex>&, const Mutex&);
template <class Mutex> bool operator==(const Mutex&, const scoped_lock<Mutex>&);
instead of Mutex* scoped_lock::mutex() const;
?
That's just my 'is_associated_with' with a different name. It's a bit more limited than mutex(); for example, you can't use a map<void*, ...> keyed on mutex(), and you can't compare l1.mutex() and l2.mutex() (using std::less<void*>) to derive a locking order.
Do you have data on whether your platforms support pthread_mutex_timedlock?
I have one platform to support where I preferred a different implementation for mutex and try_mutex: Win98. Admittedly that one is quickly going obsolete. Nevertheless I currently still need to support it.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ dllproc/base/tryentercriticalsection.asp
TryEnterCriticalSection
Requires Windows XP, Windows 2000 Professional, or Windows NT Workstation 4.0.
Have you seen Alexander's 'swap-based' implementation? The link was in my original post, right after "It is true that Windows 95 does not have TryEnterCriticalSection, but an implementation can use Alexander Terekhov's alternative:" http://lists.boost.org/MailArchives/boost/msg64648.php
Mac OS X up through 10.3.4 (most current) does not appear to support pthread_mutex_timedlock, and so on this platform my mutex implementation differs from my timed_mutex implementation.
Not good. This means that you cannot be persuaded to abandon timed_mutex, which in turn means that the future standard will probably have a timed_mutex, even if at that future time Mac OS X does have pthread_mutex_timedlock. The alternative reality would have a mutex with timed_lock #ifdef'ed on _POSIX_TIMEOUTS until conformance arrives.