https://community.intel.com/t5/Intel-Moderncode-for-Parallel/HLE-XRELEASE/m-p/807073#M864 <P>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.)</P><P>In the reference manual:</P><P>{</P><P>8.3.3 Requirements for HLE Locks</P><P>...</P><P>An XRELEASE prefixed instruction must restore the value of the elided lock to the</P><P>value it had before the lock acquisition.</P><P>}</P><P>While following this rule different sections of a protected structure can be concurrently updated, as shown in your example (provided non-conflicting updates).</P><P>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?</P><P>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.</P> Fri, 17 Feb 2012 15:36:04 GMT jimdempseyatthecove 2012-02-17T15:36:04Z https://community.intel.com/t5/Intel-Moderncode-for-Parallel/HLE-XRELEASE/m-p/807073#M864 <P>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.)</P><P>In the reference manual:</P><P>{</P><P>8.3.3 Requirements for HLE Locks</P><P>...</P><P>An XRELEASE prefixed instruction must restore the value of the elided lock to the</P><P>value it had before the lock acquisition.</P><P>}</P><P>While following this rule different sections of a protected structure can be concurrently updated, as shown in your example (provided non-conflicting updates).</P><P>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?</P><P>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.</P> Fri, 17 Feb 2012 15:36:04 GMT https://community.intel.com/t5/Intel-Moderncode-for-Parallel/HLE-XRELEASE/m-p/807073#M864 jimdempseyatthecove 2012-02-17T15:36:04Z