|
@@ -74,22 +74,23 @@ Causes of transaction aborts
|
|
Syscalls
|
|
Syscalls
|
|
========
|
|
========
|
|
|
|
|
|
-Performing syscalls from within transaction is not recommended, and can lead
|
|
|
|
-to unpredictable results.
|
|
|
|
|
|
+Syscalls made from within an active transaction will not be performed and the
|
|
|
|
+transaction will be doomed by the kernel with the failure code TM_CAUSE_SYSCALL
|
|
|
|
+| TM_CAUSE_PERSISTENT.
|
|
|
|
|
|
-Syscalls do not by design abort transactions, but beware: The kernel code will
|
|
|
|
-not be running in transactional state. The effect of syscalls will always
|
|
|
|
-remain visible, but depending on the call they may abort your transaction as a
|
|
|
|
-side-effect, read soon-to-be-aborted transactional data that should not remain
|
|
|
|
-invisible, etc. If you constantly retry a transaction that constantly aborts
|
|
|
|
-itself by calling a syscall, you'll have a livelock & make no progress.
|
|
|
|
|
|
+Syscalls made from within a suspended transaction are performed as normal and
|
|
|
|
+the transaction is not explicitly doomed by the kernel. However, what the
|
|
|
|
+kernel does to perform the syscall may result in the transaction being doomed
|
|
|
|
+by the hardware. The syscall is performed in suspended mode so any side
|
|
|
|
+effects will be persistent, independent of transaction success or failure. No
|
|
|
|
+guarantees are provided by the kernel about which syscalls will affect
|
|
|
|
+transaction success.
|
|
|
|
|
|
-Simple syscalls (e.g. sigprocmask()) "could" be OK. Even things like write()
|
|
|
|
-from, say, printf() should be OK as long as the kernel does not access any
|
|
|
|
-memory that was accessed transactionally.
|
|
|
|
-
|
|
|
|
-Consider any syscalls that happen to work as debug-only -- not recommended for
|
|
|
|
-production use. Best to queue them up till after the transaction is over.
|
|
|
|
|
|
+Care must be taken when relying on syscalls to abort during active transactions
|
|
|
|
+if the calls are made via a library. Libraries may cache values (which may
|
|
|
|
+give the appearance of success) or perform operations that cause transaction
|
|
|
|
+failure before entering the kernel (which may produce different failure codes).
|
|
|
|
+Examples are glibc's getpid() and lazy symbol resolution.
|
|
|
|
|
|
|
|
|
|
Signals
|
|
Signals
|
|
@@ -176,8 +177,7 @@ kernel aborted a transaction:
|
|
TM_CAUSE_RESCHED Thread was rescheduled.
|
|
TM_CAUSE_RESCHED Thread was rescheduled.
|
|
TM_CAUSE_TLBI Software TLB invalid.
|
|
TM_CAUSE_TLBI Software TLB invalid.
|
|
TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap.
|
|
TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap.
|
|
- TM_CAUSE_SYSCALL Currently unused; future syscalls that must abort
|
|
|
|
- transactions for consistency will use this.
|
|
|
|
|
|
+ TM_CAUSE_SYSCALL Syscall from active transaction.
|
|
TM_CAUSE_SIGNAL Signal delivered.
|
|
TM_CAUSE_SIGNAL Signal delivered.
|
|
TM_CAUSE_MISC Currently unused.
|
|
TM_CAUSE_MISC Currently unused.
|
|
TM_CAUSE_ALIGNMENT Alignment fault.
|
|
TM_CAUSE_ALIGNMENT Alignment fault.
|