mp atomicity advice?

[golfmiketango]

Is there any official (or conventional) "best practice" I can follow if I want a mutex or lock of some kind, to muck around with the "global" global, or something hanging off of it, atomically?

For example (not my actual use-case) if I am making some kind of custom per-player money system, is there some safe procedure to debit player "a" and credit player "b" with minimal possibility of double-spending and/or vaporizing cash, assuming my virtual money is just an integer stored in global.player_wallet[player_index]?

[eradicator]

Each mod has its own Lua instance and own global table to store data.

I.e. no other mod can change your mods money integers. The "global" table is only global in the lua sense that it is not a local variable.

[golfmiketango]

Yes, I know. I'm shooting for, "won't cause a desync in multiplayer," not "can't trample another mod's data".

Also, to be clear, I know all about the dining philosophers and all that stuff.... it's an API concurrency question, not a "how do I do concurrent programming correctly" question.

[posila]

As a mod developer you don't need to concern yourself with concurrency, because control.lua is not a concurrent environment. All clients will execute all lua events in the same order, and lua events are not executed in parallel.

[eradicator]

Well. I have no clue how complex your "not your actual use-case" money-spending system is supposed to be. But causing desyncs isn't easy. As long as you don't do something stupid like storing persistent data in a local variable. Something simple as

Code: Select all

local function money_transfer(wallet1, wallet2, transfer)
  wallet1 = wallet1+transfer
  wallet2 = wallet2-transfer
end

certainly isn't going to cause any desyncs.

And your question is too vague to give sensible advice regarding what you're actually trying to do

[golfmiketango]

OK, so, by whatever magical method, my mod's event-driven code effectively has a global lock on all shared game state including the global global?

For example, if player 1 and player 2 both press a GUI button to transfer all of their money to the other player at tick t, at tick t+1 one player will always end up with all the money? Can I assume anything about which player's code runs first?

[DaveMcW]

For example, if player 1 and player 2 both press a GUI button to transfer all of their money to the other player at tick t

Both events will be called sequentially at tick t. When your mod is finished handling them, the player whose event was processed first will have all the money at tick t.

I don't know why you care which player's code runs first, someone has to win a tie but it doesn't matter who.

[eradicator]

OK, so, by whatever magical method, my mod's event-driven code effectively has a global lock on all shared game state including the global global?

I think the method would be called "event queue" or "single threaded execution". Everything happens in sequence. (Also as stated before the global "global" is not a shared table.)

For example, if player 1 and player 2 both press a GUI button to transfer all of their money to the other player at tick t, at tick t+1 one player will always end up with all the money?

In the unlikely event they actually managed to press in the same tick. Yes

Can I assume anything about which player's code runs first?

No. You do not even know if anyone else pressed any keys at all. As you get all events in order and each event only tells you about one player pressing a key. Of course you could store all the event data from tick t somewhere and then in tick t+1 look at the stored data to see if more than one player pressed a key. But i have no idea why you would want to do that.

[posila]

OK, so, by whatever magical method, my mod's event-driven code effectively has a global lock on all shared game state including the global global?

For example, if player 1 and player 2 both press a GUI button to transfer all of their money to the other player at tick t, at tick t+1 one player will always end up with all the money? Can I assume anything about which player's code runs first?

GUI click will create input action that is sent to server, server will put input actions it receives into sequence and sends then to clients, when client receives sequence of input action from server it exectutes them in series. In case of clicking on mod GUI executing input action means dispatching an event to Lua. I am not 100% sure, but I think server sorts input actions by player index.

[golfmiketango]

Groovy, thanks for the free science packs guys!

[eradicator]

I am not 100% sure, but I think server sorts input actions by player index.

Oh. It actually resorts them instead just keeping the (random) order they were recieved in? Interesting.

[Rseding91]

I am not 100% sure, but I think server sorts input actions by player index.

Oh. It actually resorts them instead just keeping the (random) order they were recieved in? Interesting.

Yes, all things must be deterministic. It makes automated tests that things are correct *much* easier if running the same inputs produces the same outputs every time. That's something we can verify on every platform we support.