Mike,

...

And I feel that the interface (representing convenience, flexibility, usability, etc.) is the first thing that a library will be judged by.

Perhaps, but the next thing it will be judged by is efficiency and speed. Ultimately, many C++ programmers won't use even the cleanest and most elegant designs if they result in code that isn't fast enough or efficient enough--especially in something like a multi-threading library.

Peter Dimov's argument, if I understand correctly, is that the "cleaner" design could be made as fast/efficient as the current one, not that we should choose a cleaner design at the expense of speed or efficiency.

[Batov, Vladimir] I never advocated forgetting efficiency. Only that the first thing needs to be addressed/settled on first. Then, we move on to the second within the constraints of the first choice.

...

I feel that for the user having different types of mutexes is inconvenient and unnecessary restricting.

Inconvenient I can see, but how is having more choices restricting?

[Batov, Vladimir] It is restricting because I presume that different types of mutexes will have different functionality. Therefore, the plain mutex will not have something I need for try_lock. If that assumption of mine is not correct and, say, try_mutex is complimentary -- an efficient implementation of the generic mutex (with efficiency vs. functionality trade-offs), then I am fine with it.

...

Having additional (and maybe unused) data in a mutex does not seem like a huge problem

Not for you, perhaps, but I can guarantee that there are others who don't feel that way.

[Batov, Vladimir] True. I am fine if we address the mainstream use first (that is, a generic mutex represents an access serialization to the relevant data with the *kind* of serialization (timed, try, etc.) refined by locks). Then, mutex refinements will be just that -- refinements for a particular purpose. Like generic mem. allocation mechanism (kinda OK for everyone) vs. optimized (extremely good for some).

...

(as long as it does not impose performance penalties) --s memory is cheap and mutexes are not usually created in huge numbers.

Memory isn't cheap for everybody: there are still some (many?) who are forced to work in more constrained environments. For instance, programmer's of handheld devices often deal with insufficient memory problems.

[Batov, Vladimir] True. That falls into the same specialization category. I simply do not want that specialization at the expense of the mainstream users/applications.