Skip to main content
Computer Science

Return to Answer

added 35 characters in body
Source Link
hengxin
hengxin
  • 9.6k
  • 3
  • 37
  • 74

So nowhere in this scenario is T1 executed again?

"Retry" is not among the main topics of the classic STM paper.

You can let the initiator of $T_1$ call StartTransaction() (treat $T_1$ as a new transaction) upon each Failure until it receives a Success. The authors have just ignored it probably because they want to focus on the ingenious STM concept.

Retry is of course a big topic itself, for instance, in Composable Memory Transactions.

So nowhere in this scenario is T1 executed again?

"Retry" is not among the main topics of the classic STM paper.

You can let the initiator of $T_1$ call StartTransaction() upon each Failure until it receives a Success. The authors have just ignored it probably because they want to focus on the ingenious STM concept.

Retry is of course a big topic itself, for instance, in Composable Memory Transactions.

So nowhere in this scenario is T1 executed again?

"Retry" is not among the main topics of the classic STM paper.

You can let the initiator of $T_1$ call StartTransaction() (treat $T_1$ as a new transaction) upon each Failure until it receives a Success. The authors have just ignored it probably because they want to focus on the ingenious STM concept.

Retry is of course a big topic itself, for instance, in Composable Memory Transactions.

Source Link
hengxin
hengxin
  • 9.6k
  • 3
  • 37
  • 74

So nowhere in this scenario is T1 executed again?

"Retry" is not among the main topics of the classic STM paper.

You can let the initiator of $T_1$ call StartTransaction() upon each Failure until it receives a Success. The authors have just ignored it probably because they want to focus on the ingenious STM concept.

Retry is of course a big topic itself, for instance, in Composable Memory Transactions.