thread.req.timing

[Viacheslav Usov]

thread.req.timing has some peculiar language in clauses 3 & 4.

Clause 3 says an implementation 'should' use a steady clock. The use of 'should' means it is not mandatory, so it can be any other clock. Effectively that means that the clock used might be one which allows time adjustment, which can result in timeouts potentially infinite, or at least much longer than might be expected by the (naive) user. This also mean that any code using the facilities covered by clause 3 is implementation-dependent and generally non-portable.

Clause 4 says an implementation 'should' use (for a different but related function) whatever clock the timepoint argument was derived from, yet, after some elaboration, it says, effectively, that the overall timeout 'shall' be bounded using a steady clock. The use of 'shall' means such bounding is mandatory, so the timeouts cannot be infinite, so even the naive user can write code with predictable behaviour. There is still a degree of implementation dependency, but the upper bound makes the code reasonably portable.

My question here is, if the standard does make the use of a steady clock mandatory in one case, and recommended in the other case, why is it simply not mandatory in both cases?

What is (or was) the rationale for allowing the clause 3 variety to be essentially non-portable? Clause 5 seems to indicate that the committee understood that the present specification is not reliable per se.

Note that when I say "implementation-dependent" I do not mean the D_i and D_m.

Cheers,

V.

[Victor Dyachenko]

I in turn wonder why steady_clock is mandatory when CLOCK_MONOTONIC is optional (as defined by POSIX http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html)

[Thiago Macieira]

Conclusion: systems without a monotonic clock are not supported by C++.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center