Changes between Version 2 and Version 3 of Ticket #5862, comment 8
- Timestamp:
- 01/07/18 03:05:26 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #5862, comment 8
v2 v3 1 This is still a problem, it is just non-deterministic and requires you to get unlucky and have the engine lock its mutex and make a call to the audio mixer after the audio mixer has already locked its mutex but before it has called the engine’s audio callback. With the reduced audio buffer in ScummVM 2.0 this is less likely but the root problem isn’t solved until the double-mutexes are removed, the data members access by both threads are is replaced with lockless atomics (which OSystem does not have), the audio thread stops making callbacks while holding a lock (C++ Core Guidelines CP.22), or the lock attempts are made non-blocking (also not a feature that OSystem has).1 This is still a problem, it is just non-deterministic and requires you to get unlucky and have the engine lock its mutex and make a call to the audio mixer after the audio mixer has already locked its mutex but before it has called the engine’s audio callback. The root problem isn’t solved until the double-mutexes are removed, the data members access by both threads are is replaced with lockless atomics (which OSystem does not have), the audio thread stops making callbacks while holding a lock (C++ Core Guidelines CP.22), or the lock attempts are made non-blocking (also not a feature that OSystem has).
