[James Ross]

Csantucci, on 08 February 2015 - 11:53 PM, said:

I would like to have this clarified better: you say:
"Nobody modifies the value in-place (as in, adding items to the List) - everybody must modify the value in a copy and replace the whole value in a single assignment (which is atomic)."
Referring to a list this would mean for the process modifying the list:
- make a local copy of the list (which is atomic, while generating an array from the list is not atomic)
- modify the local copy
- copy back the local copy to the original copy; (which is again atomic)
while for the process accessing the above list to operate on it it would mean
- make a local copy of the list (atomic operation)
- work on the local copy.

Did I understand correctly?

Pretty close, but you need to differentiate reading the field and creating a new List from the existing one when using "atomic".

Reading and writing the value from the field is atomic. It's just reading and writing a pointer, which is guaranteed to be atomic. Pretty much everything else is not guaranteed to be atomic. Calling any methods/constructors, such as making a copy of the list with "new List", just like turning it in to an array with "ToArray", is not atomic.

The reason that doing "SharedField.ToArray()" is probably fine is that it is implicitly reading the shared field just once, to call a method on it.

The key things to remember are:

• Never modify an object in a shared field - once you've assigned a List to the field, you must never change that List again, it can only be replaced with a new List.
  
• Only read the field once in each place that uses it - otherwise you may get different Lists if the field has been replaced while the code was running. (If you're doing a for (var i loop this is especially important.)

[Csantucci]

Thanks James,
if you could point me to an implemented example within the OR code that would be the top. But only if you want. At the moment I leave the patch as it is, but accept if someone improves it.

[James Ross]

Csantucci, on 09 February 2015 - 03:20 AM, said:

if you could point me to an implemented example within the OR code that would be the top. But only if you want. At the moment I leave the patch as it is, but accept if someone improves it.

I think the only code that supported multiple threads modifying a shared list was my attempt at fixing the sound sources previously, which had some problems which I didn't investigate (as they didn't happen to me).

For a single thread modifying data which is used in other threads, see any of the following:

• Terrain: TerrainViewer.Load()
  
• Tiles: TileManager.Load(int tileX, int tileZ, bool visible)
  
• Trains: TrainDrawer.Load() (the indentation is a bit messed up in the online viewer here)

The tile code in particular is quite a good example: it shows how you do this operation with a List and a Dictionary as a single unit.

Edit: As you can see with the examples above, generally speaking all of the loading code should follow this pattern since the Loader Process is modifying data, while both Updater Process and Render Process are consuming it. Not certain 100% of the loading code is this safe though, so focus on these examples in preference to other loading code.

[Csantucci]

James,
thank you for your readiness to explain.