On Jul 12, 2004, at 4:39 PM, Peter Dimov wrote:
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. ;-)
Sorry, I missed the "private" declaration. And I like the idea of standardizing the interface for the purpose you state. I'd be tempted to make them public so that they could be used outside of a lock, or with user-written locks. (e.g. someone writes a read/write lock that is better than what we're dreaming of). We can still standardize an interface, but not require the entire interface. E.g. here's what you must have: void lock(); void unlock(). And if you want to try-lock, you have to also provide: bool try_lock(); And if you want to provide timed-locks... And if you want to provide read-lock... And if you want to provide write-lock... And if you want to provide upgradable-read-lock... Personally I'm a little giddy over the try-timed-upgradable-read-lock, but hey, it could really be useful in just the right circumstance. But I wouldn't want to pay for that if I just needed a simple lock. Who knows, there might even be an application for a read (but not write) lock? Everybody can concurrently access this structure, but you must "register" yourself first by obtaining this read-lock... <shrug> no practical application in mind, just brainstorming. And then there's recursion, same interface but slightly different functionality... maybe: class Im_a_recursive_mutex { public: typedef int recursive; ... }; ? Nested types can be detected at compile time, so clients (locks or whatever) can figure out what they're dealing with (and a helpful utility traits provided to do this). We provide an extendable mutex concept that can plug & play with an extendable lock concept, provide a few example mutexes and locks, and turn the world loose on it to continue the work?
[...]
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.
Yeah, but with prettier spelling. ;-)
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.
<nod> good points. Perhaps all 6 relationals should be added to the (public) basic mutex interface? In C++0X if containers are move-aware and mutexes movable, then you could then map<mutex, ...>.
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:"
<nod> I truly appreciate Alexander's continued willingness to publish algorithms such as this. Thanks Alexander!
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.
<sigh> It isn't just Mac OS X either. There are other (embedded) platforms I've neglected to mention because I'm not positive exactly what my NDA is. But it can get pretty ugly out there in some cases. If OS's would just adopt the pthreads knowledge and experience the world would be such a better place. Multithreading is a tough area and OS designers aren't necessarily experts in that particular area (and I'm not claiming to be either). And without the proper OS functionality, add-on threading libraries are inherently limited. ... No point I'm trying to make. Just being grumpy. ;-) -Howard