[KiwiPeter]

Seemingly random crashes:

Attached File(s)

•  OpenRailsLog.txt (89.24K)
  Number of downloads: 180

[Csantucci]

I just got the same problem on the MEP route, during debugging, when switching view from one train to another through the Alt-9 command.

[dennisat]

I've had quite a number of these and my tracing has led to the conclusion that the new compare/exchange serialisation cannot protect a dictionary which is, in effect, a list of lists. I understand that compare/exchange can only protect contiguous items of data, not many separate items which is what a dictionary must usually be.

Dennis

Edit
Try reducing sleep time to 5ms - it will crash all the time.
Restore the lock processing - it will work fasultlessly.

[cjakeman]

 dennisat, on 06 December 2014 - 01:23 PM, said:

new compare/exchange serialisation

Must have missed this. What is it, please?

[dennisat]

Interlocked compare / exchange is a method that can be used to make safe updates to data that can be updated by more than one thread. The problem with using it on the sound sources dictionary is that the dictionary only points to other lists. Compare / exchange protects the copy of the dictionary but does not, as far as I can tell, copy the lists that the dictionary is pointing to. You therefore end up with two dictionaries pointing to the same underlying data. Thus the conflict.

Dennis

[cjakeman]

Very clear. Thanks, Dennis.

[Csantucci]

 dennisat, on 06 December 2014 - 01:23 PM, said:

Restore the lock processing - it will work fasultlessly.

Dennis,
can you please post a patch for this? I just had again the crash, see attached file.
 OpenRailsLog.txt (12.62K)
Number of downloads: 162

[dennisat]

 Csantucci, on 10 December 2014 - 09:54 PM, said:

can you please post a patch for this? I just had again the crash, see attached file.

I have not totally dispensed with the Interlocked Compare Exchange because I understand the reasons for getting away from Lock processing. Locked code can cause bad bottlenecks. Since the Update process was spending the most time in the locked state I've therefore made it interruptible and restartable (sort of) using Compare Exchange. This allows the short Add and Remove Soundsource processes access immediately they need it. These processes are used in bursts when tiles are loaded/unloaded and AI trains are created/removed. If they are held up, they can be a contributory cause of the game stuttering. I've also made Sleeptime variable depending on the sound update response time in an effort to allow heavy bursts of activity through more quickly. To this end, I've also removed the "once every 4 cycle update except for NeedsFrequentUpdate" code. I'm afraid a lot of my debugging / monitoring code is in this patch; some of my stats calculation in cases of heavy interruption of the Update process leaves something to be desired but it was good enough for my purposes. I have some very sound dense activities and I was getting these crashes as soon as the new method of serialisation was introduced.

The Sound Debug Form also crashes randomly because of the same problem. Just leave the form up while running the game, it will crash sooner or later. I haven't looked at how to cure that yet. I hope this gives you some ideas about a more elegant and permanent solution. The patch is based on X2698


Dennis

 SoundProcess__ElvasTower.zip (2.26K)
Number of downloads: 185

[Csantucci]

Thanks Dennis,
this is something that goes beyond my knowledge. I hope that someone else will tackle the problem.

[Csantucci]

Bug report created.