Blocks placed/mined desync with blockcount in inventory

[AnorZaken]

Cause: I'm taking an educated guess that the mining/placing of blocks is multithreaded and you dont use locks to ensure thread-safety on incrementing/decrementing the blockcount in the inventory?

The problem: If you mine/place blocks very fast, the amount of blocks gained/lost in the inventory does not match the amount of blocks removed/placed in the world.

Consequence: if you place, say 100blocks, in a straight line (as fast as you can), you will loose around 90~100blocks from your inventory. It's varies randomly. Same thing if you mine blocks very fast: after placing out 100blocks normally, mine them up clicking as fast as you can with your mouse: you will most likely not get 100blocks back into your inventory.

Bottom line: Having blocks randomly pop in and out of existance, randomly gaining and loosing blocks from the inventory when you build big things fast, is annoying. It can ofcourse be exploited by placing out a lot of blocks fast and mining them back slowly, resulting in a net gain in total amount of blocks, but doing so with anything other than factionblocks the pay-off would probably not be worth the time.

 

[AnorZaken]

For non-programmers curious about what the suggested cause is about, here is a short technical explanation:

increasing a value (any value) on a computer is most often (depends on cpu architecture) three operations on the cpu: 1. read the old value into the cpu-cache, 2. change this value (in the cache), 3. write the value (from the cache) back into ram.

The thing is that if you have multiple threads doing this at the same time, there can be sync issues (because by design there is no guarantee as to when any of the instructions actually run - this is beyond a simple explanation). Learning by example:
The \'value\' is initially 5.
We do two increment operations in rapid succession (in two different threads!)
Our intention is to get the value 7.
ThreadA: Reads the value from ram to cache - it is 5.
ThreadA: Increments the value in the cache - it is now 6 (in threadA cache).
ThreadB: Reads the value from ram to cache - it is still 5 in ram.
ThreadA: Writes the value 6 from its cache into ram. (threadA is finished!)
ThreadB: Increments the value in its cache - from 5 to 6.
ThreadB: Writes the value 6 from its cache into ram. (threadB is finished!)
The final number stored in ram is not 7, it is 6.
(And for anyone interrested the remedy is called \'locks\' - they lock access to a value so only one thread at a time can access it.)

 

[starcitsura]

I\'ve seen this a lot. I assumed it had something to do with the way block counts were being reconciled between the client and the server.

 

[Morrigi]

Confirmed. It just ate a few of my hull blocks and AMCs today.