Doc. No.: | WG21/N2528 J16/08-0038 |
---|---|
Date: | 2008-2-1 |
Reply to: | Hans-J. Boehm |
Phone: | +1-650-857-3406 |
Email: | Hans.Boehm@hp.com |
The current working paper in 30.3.2 defines a TimedMutex requirement and two implementations timed_mutex and timed_recursive_mutex. This was voted in, along with the threads API ( N2497), at the Kona meeting. Discussion in the review committee ( N2516) suggests that we should seriously consider removing this entire section, and reconsider it for TR2.
There appear to be some legitimate uses. A real-time system might use a fall-back algorithm if it cannot acquire a lock in a given amount of time. It's at least conceivable that one might want to run a deadlock detection algorithm if a mutex acquisition times out. Some uses of trylock may want to wait for a short period before giving up. (Though in many cases, it's used to avoid context switches, and this wouldn't make sense.)
Doug Lea described use cases for the Java facility (reproduced with permission):
My take on (Java) usage is that timeouts for locks are most often there to (1) help detect and deal with saturation (database locks not becoming free promptly etc), (2) for heuristically detecting or papering over deadlock-proneness (not as sleazy as it sounds), and (3) one ingredient for ensuring all-or-nothing deadline processing or meeting QoS.Finally the implementation cost of timed_mutexes is very low. Howard Hinnant's prototype implementation uses a total of 76 lines.None of these are "core" applications, but I don't like the thought of killing them completely and requiring hand-rolled solutions (which are not hard given timed condition waits, but also not trivial).
Note that none of the above usages are likely to require low-overhead highly scalable solutions, so letting them hit slower implementation paths should be fine.
However, as Howard Hinnant has pointed out, it would have been impractical for the C++ working paper to use the second approach. This would significantly slow down the standard mutex implementation on platforms that don't intrinsically provide this functionality. Although it may be acceptable to slow down timed mutex acquisitions, it is clearly not acceptable to slow down all mutex acquisitions in order to support a relatively infrequently used facility.
Since Posix provides pthread_mutex_timedlock only as part of a separate option, even some Posix platforms do not support it. It appears that a Windows implementation would have similar issues. Hence this slowdown for ordinary mutexes would be encountered on many platforms.
Thus the current interface appears to unavoidably diverge from Posix, another important ISO standard, and it appears to be less useful than Posix, though there is disagreement on how important this difference is.
A somewhat superficial examination of occurrences of the Boost and Posix facilities (using Google code search) showed up few uses (roughly 50 and 300 occurrences respectively, mostly in implementations and test suites). Clearly legitimate uses appeared infrequent.
Even if a timed_mutex is essential to a particular piece of code, it is still easy to reimplement, e.g. using the same 76 lines of code from Howard Hinnant's reference implementation. It is not at all clear that anyone incapable of reimplementing timed_mutex would be able to use it correctly either.
There is no evidence that this is a critical facility that needs to be in the initial version of the standard. Part of the reason for supporting it on other platforms appears to be to support real-time applications, which we do not support well at this stage in any case.
Postponing consideration may make our job easier in either of the following two cases:
Note: This has no impact on timed condition variable waits and hence the need to specify times and durations.