Distributed asynchronous Message Framework building notes 5--How to avoid data sharing traps in parallel programming

Any multithreaded/parallel/distributed will face a problem with "data state sharing".

Experienced developers will say that if you want to avoid avoiding state sharing correctly and effectively, you should not share it in any state .

It's a good idea, though, but without state sharing, how do you need to know the status of non-local data?

Perhaps you would say that using messages and using messages, our ugly callback pyramid should be stacked higher.

I have to say that this is a solution, but to keep the state from being modified, we also have to apply a write lock remotely to prevent the data from being modified by another task.

Then the process is application lock-"Request a message status-" release lock

Suppose we have a simple trading task, the player on service A is 1 ready and player 2 on Server B is ready to trade.

Player A needs to pay 100 coins, Player B needs a knife in the backpack to player A.

Non-distributed simplicity is simple

if (Player A. Gold >100 && Player B. Possession (knife)) {

Player A. Gold coin-=100;

Player A. Get (knife);

Player B. loss (knife);

}

To prevent logic from failing, this logic is perfect, simple and effective if there is a transaction error and a rollback.

So if it is distributed this is more troublesome, try to write a synchronous method, remote call to compare time, but at least can work normally.

Sv1. Lock (Player a)

Sv2. Lock (Player B)

if (sv1. Player A. Gold >100 && sv2. Player B. Possession (knife)) {

Sv1. Player A. Gold-=100;

Sv2. Player A. Get (knife);

Sv3. Player B. loss (knife);

}

Sv1. Release (Player a)

Sv2. Release (Player B)

This time it should be asynchronous to optimize this call.

Sv1. Lock (Player A, () {

Sv2. Lock (Player B, () {

if (sv1. Player A. Gold >100 && sv2. Player B. Possession (knife)) {

sv1. Player A. Gold coins (-+, () {

Sv2. Player A. Get (knife, () {

sv3. Player B. Lose (knife, () {

SV1. Release (Player A, () {

Sv2. Release (Player B, () {

});

});

);

});

});

}

})

});

I really want to make sure that I'm not funny.

If you keep the logic that you previously imagined:

1. All executions of a single object are single-threaded. (Data access unique)

2. When the object is not local, commit to remote execution and return the result.

3. After the results are obtained, continue to execute locally

The trading initiation will be initiated by player A, we clone a player B Mirror and mark a valid time.
All modifications have an action tag. Then the logic of player A and player B is executed on player a thread.

However, because we manipulate the image, it does not affect the original data.

After the operation logic is not successful, we need to get the difference between the player A/b and the transaction before the operation is completed.

How to get a reference before the article, and then to the time we really want to write.

Player A waits for a lock (that is, temporarily does not perform other requests), remotely requesting player B's write.

When finished, player a writes. Release the wait lock.

There is an error-proof lock at the moment of writing, and no other time affects any other operation.

If the remote server is modified at the moment of the transaction initiation, then the write fails, as long as the difference data is discarded and the lock is released .

From the above logic we can see

1. Data access only lets us not worry about being modified during execution, which means that we can deduce that any non-multi-step operation is successful. (the method does not contain a remote method and is bound to succeed)
2. Thread switching mechanism to ensure that we run the correct location when writing code, because you do not need to determine whether remote execution, only through the proxy call.

3. Unless the transaction, to ensure that the operation of the parties must be successful, otherwise, no lock, that is, secure cross-service operation.

Distributed asynchronous Message Framework building notes 5--How to avoid data sharing traps in parallel programming