|
From: John R. <jr...@bi...> - 2013-06-20 16:18:37
|
On 06/20/2013 08:59 AM, Julian Seward wrote: > On 06/20/2013 05:33 PM, John Reiser wrote: >>> (1) translate "XBEGIN fail-addr" as "goto fail-addr"; that is: push >>> simulated execution directly onto the failure path. This is simple >>> but will have poor performance, if (as is likely) the failure path >>> uses normal locking and is not tuned for speed. >> >> That strategy might induce a deadlock, infinite loop, or application failure >> in some cases. For example, one fallback strategy for the application when >> the transaction fails is: grab a larger lock (more powerful) which >> logically guarantees that the transaction will succeed, then re-run >> the transaction while holding that lock. > > Are you sure about that? The transaction might fail for entirely arbitrary > reasons, such as resource exhaustion (for conflict tracking) in the hardware > or due to a context switch whilst inside the transaction, so the fallback > path must always be usable. Hence not providing a usable fallback path is > a straight-out application bug. The lock might guarantee that P(failure) < (1.0 - delta) for non-infinitesimal delta > 0. For instance, the lock might guarantee no [other] memory accesses to the relevant memory region, no context switching, no other XBEGIN (in the strongest case: no other process, and no other thread), etc. Thus progress will occur unless VG forces perpetual failure. -- |