HLE - XRELEASE

HLE - XRELEASE

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.