Note that there are some explanatory texts on larger screens.

plurals
  1. POResolving concurrency problem around collections
    primarykey
    data
    text
    <p>I'm having issues with concurrent usage of a shared collection with a multi-player synchronous game I'm working on. I did some digging around and found a neat thread-safe IEnumerator/IList implementation on Alexey Drobyshevsky's post on codeproject here:</p> <p><a href="http://www.codeproject.com/KB/cs/safe_enumerable.aspx" rel="nofollow noreferrer">http://www.codeproject.com/KB/cs/safe_enumerable.aspx</a></p> <p>After adopting his implementation I have even replaced all Linq queries on the shared collection with for/foreach loops because the Linq queries were still using the unsafe IEnumerable underneath.</p> <p>Here's my implementation of the SafeList, and the list itself is being exposed to as a ReadOnlyCollection to the consuming classes.</p> <p><a href="http://theburningmonk.com/2010/03/thread-safe-enumeration-in-csharp/" rel="nofollow noreferrer">http://theburningmonk.com/2010/03/thread-safe-enumeration-in-csharp/</a></p> <p>After switching to this SafeList I am seeing far less problems, but under heavy load (80+ threads all of which read/write from and to the list at different points) I'm still seeing InvalidOperationException being thrown:</p> <blockquote> <p>The element list has changed. The enumeration operation failed to continue</p> </blockquote> <p>I have even tried using ReadWriterLockSlim in place of the lock object in my implementation of the SafeList but that proved fruitless too. The only other suggestion I have had so far is cloning the list every time a threads needs to loop through it. I'm hoping to avoid cloning the list every single time as the list is being used in way too many places it might be a performance hit and might introduce other bugs that are difficult to spot.</p> <p>Given the time constraints I'll have to be pragmatic about it and if cloning is the safest and quickest way to go about solving this problem then I'm fine with it, but before resorting to this last ditch-attempt I'm just wondering if anyone out there has come across something similar is able to offer some advice.</p> <p>Many thanks in advance!</p> <p>[EDIT] Here is a little more information about the problem I'm seeing as requested:</p> <p>For one 'game', there can be up to 100 or so synchronous clients connected and the game needs to message each connected client with updates every few seconds and so every few seconds this game needs to iterate through the shared list of players. When a player joins, or leaves, the list needs to be updated accordingly to reflect the changes. To add to that, the players can interact with the game and chat to other players, and every time a message is received from the player the game would again need to iterate through the same list and do a broadcast. The exceptions are typically thrown when the game is trying to broadcast messages to players (read operation) at the same time as many players leaving/joining (write operation) at the same time.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COI feel like this question is "I'm juggling seven flaming swords and I keep getting burned even though I'm wearing asbestos gloves; what do I do?" You *stop juggling seven flaming swords*, that's what you do. Juggle three beanbags instead, it's a lot safer. 80 is a ludicrous number of threads, and that all of them require access to one mutable list seems like a design decision that is fraught with peril. Make your life easier; design your application to require far fewer threads and carefully limit the mutable state visible on multiple threads to as little as possible.
      singulars
    2. COYou'll probably get more helpful answers if you outline the rough structure of the mutable data that is shared between your threads. It sounds like you need to pick the right data structure; the kinds that work for single threads don't work very well for multiple threads.
      singulars
    3. COI'm sorry but you're going to need to rewrite it. Otherwise you're going to be spending literally *years* finding hangs and crashes that occur every few months. I wasted much of the years 1997 through 2003 on finding and hopelessly patching a mound of poorly structured multi-threaded code. Then I rewrote it in a much simpler form, so it ran faster and never has any such problems. The investment in rewriting it on a sane basis will be repaid easily. A poorly structured multi-threaded program cannot be fixed with local patches here and there. It can only be redesigned.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload