One of the advantages of HLE and RTM locks not highlighted in your post, or in the reference specification, is this reduces (if not eliminates) the need for Wait-Free programming. Use of HLE or RTM removes the nasty side effect of preempting a thread holding a lock, which is principally the reason for writing code in Wait-Free format. (Wait-Free avoids lock held for duration of preemption.)

In the reference manual:


8.3.3 Requirements for HLE Locks


An XRELEASE prefixed instruction must restore the value of the elided lock to the

value it had before the lock acquisition.


While following this rule different sections of a protected structure can be concurrently updated, as shown in your example (provided non-conflicting updates).

Why not permit an XRELEASE performed to a different value to cause the first such release to win and all subsequent XRELEASE (XEND) to abort?

An example of this might be an XACQUIRE that sets a lock flag in the lsb of a pointer, then using the pointer to the object to reference the object. After processing, the XRELEASE may need to restore the pointer to a different value (say different pointer or NULL or different state of lock). This may occur in linked list management. While you could say in these cases do not use HLE/RTM then this exposes the problem of thread preemption.

1 post / 0 new
For more complete information about compiler optimizations, see our Optimization Notice.