As "an OpenMP guy", I'll chime in.
We are intending to have support in the next compiler release for a way to request that omp_lock_t should use an adaptive TSX lock built on RTM.
We don't think it's a good idea to change the default implementation of omp_lock_t to make it speculative, because that can potentially slow code down significantly.
p.s. If you're interested in TSX you should read chapter 12 of the new tuning guide at https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-opti...
I agree. The compiler may not know in advance if the lock is protecting an I/O operation or protecting a small critical section (using omp_lock_t). In the case of the I/O operation you likely would not want to use TSX/RTM. On the otherhand, in the case of a small critical section (using omp_lock_t) you would like to take advantage of TSX/RTM. Perhaps an alternalte omp runtime library call would suffice (you could write your own wrapper now).
The other place to recommend use of TSX or RTM is in !$OMP ATOMIC.
The !$OMP CRITICAL may be harder to please all with one policy. When the critical section is long lasting you may want the other threads to suspend. When it is short duration, then you might prefer to use TSX/RTM. Note, for short duration critical sections the user could use:
!$ CALL LOOPING_XBEGIN()
... code here ...
!$ CALL _XEND
Where LOOPING_XBEGIN() is a shell subroutine that loops when _XBEGIN aborts.