2

Is there any kind of locking protocol in ethereum, like can two transaction update the state variable same time ?, If yes then how would you avoid that ?

Smart Contract XYZ is deployed and two people want to update an variable in the XYZ, so they push transaction into the transaction pool. Now what if both transaction is executed at the same time. lets say if Transaction one wants to add 5 to the variable and transaction 2 wants to add 10 to the variable, in happy path the value in the xyz state variable must be 15(Trx 1 + trx 2), but what if both read the value same time and one of them add a block then either 5(Trx 1) is added or 10(Trx 2) is added.

2 Answers 2

4

From the smart contract's perspective, transactions are never executed simultaneously. They are executed in the order in which they appear in the mined block. You don't have to use mutexes to prevent simultaneously execution of two or more transactions, because that cannot happen by default.

You do have to think about whether you want your smart contract functions to be re-entrant or not, but that's a different problem.

Your smart contract should always be in a valid state after every transaction. You can never rely on one caller being able to perform a transaction before another caller.

3
  • 2
    I like this answer but this claim makes me a little leery. "You don't have to worry about race conditions." This depends on a coding style that always leaves a valid state after each transaction. Of course, one should always do that to avoid race conditions. My thinking is newcomers might be misled to think it's an automatic given instead of a result of their approach. Commented Dec 18, 2018 at 16:39
  • @RobHitchensB9lab Good point; edited to clarify a bit.
    – Jesbus
    Commented Dec 18, 2018 at 16:53
  • So it seems you mine the blocks first and then the smart contracts are invoked, if then it is obvious that there would be no race condition (excluding coding style as mentioned by @RobHitchensB9lab ). Commented Dec 20, 2018 at 8:27
2

One of the great things of the distributed consensus protocol is that it gets rid of physical time. "same time" does not apply to blockchain since time does not exists anymore. The consensus warrants that only a machine will mine a block. If two colliding TX try to get into the same block the ethereum specification warrants that only the first one will be executed. Order of execution depends on where the TX is placed in the block and where the block is placed in the blockchain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.