Thread: Threading/Concurrency designs

Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 70
  1. #11  
    Registered Member

    Join Date
    Oct 2008
    Posts
    2,358
    Thanks given
    146
    Thanks received
    1,041
    Rep Power
    869
    Theres oe thing called world processing logic so it has to be thought. not that simple
    Reply With Quote  
     

  2. #12  
    Chemist

    Advocatus's Avatar
    Join Date
    Dec 2009
    Posts
    2,622
    Thanks given
    201
    Thanks received
    813
    Rep Power
    1462
    Updating is read-only (no modification of any player or npc related variables) as a result it is fairly easy to multithread it. Ingame content on the other hand is subject to change at any millisecond and as a result, it would be a pain to multithread.

    Personally, the current design that I use is heavily inspired by hyperion, mainly because I feel that hyperion accomplishes it in the simplest and easiest way to debug.

    Basic design: Threads / Threadpools in use.
    -->Threads used by netty, or in teh case of hyperion mina.
    -->The threadpool used by player updating. Related to the number of cores.
    -->The game logic thread, all read and write only tasks are executed on this thread when the server is NOT updating the players. If the server is updating players, these tasks will be queued for later.
    -->The game engine thread which allows the above threads to coincide without concurrency errors.
    Quote Originally Posted by blakeman8192 View Post
    Quitting is the only true failure.
    Reply With Quote  
     

  3. #13  
    Renown Programmer

    Nikki's Avatar
    Join Date
    Aug 2008
    Posts
    3,992
    Thanks given
    553
    Thanks received
    1,078
    Rep Power
    5000
    Blake's RuneSource showed that servers don't have to be excessively threaded for amazing performance, but for better performance if your server was setup for it you should do parallel updating on all players, since it means you can update more than 1 player at a time, just make sure you are doing it correctly.
    Please don't add/pm me asking for RSPS help!

    Links:
    - Pastebin
    - Sleeksnap

    Reply With Quote  
     

  4. #14  
    Hi.

    'Mystic Flow's Avatar
    Join Date
    Nov 2007
    Posts
    7,146
    Thanks given
    256
    Thanks received
    1,252
    Rep Power
    3714
    Just as Nikki said you don't need to multithread to have max performance, my server is single threaded (Whole logic, networking is separated) and it runs perfectly fine



    Reply With Quote  
     

  5. #15  
    Banned

    Join Date
    Dec 2008
    Posts
    2,097
    Thanks given
    1,419
    Thanks received
    732
    Rep Power
    0
    Quote Originally Posted by 'Mystic Flow View Post
    Just as Nikki said you don't need to multithread to have max performance, my server is single threaded (Whole logic, networking is separated) and it runs perfectly fine
    But when multiple threads can be used to increase performance then why not use multiple?
    Reply With Quote  
     

  6. #16  
    Community Veteran


    Join Date
    Jan 2008
    Posts
    2,659
    Thanks given
    494
    Thanks received
    627
    Rep Power
    980
    Quote Originally Posted by Jimmy View Post
    But when multiple threads can be used to increase performance then why not use multiple?
    You don't know whether multiple threads actually does increase performance, or where exactly you should be using multiple threads (you don't know for sure that "player updating" is the hot spot), and multithreading adds complexity, so it's not really worth the potential performance gain if you don't need it. If it turns out that you do need to optimise (after testing your program), then you take the appropriate actions. It's up to you really, but I would say start with a simple design and profile your program first before doing things blindly.
    ~iKilem
    Reply With Quote  
     


  7. #17  
    Hi.

    'Mystic Flow's Avatar
    Join Date
    Nov 2007
    Posts
    7,146
    Thanks given
    256
    Thanks received
    1,252
    Rep Power
    3714
    Quote Originally Posted by Jimmy View Post
    But when multiple threads can be used to increase performance then why not use multiple?
    multiple threads don't always increase performance as iKilem said, multi threading helps if your machine has more then 1 core cause if you're on a single core then you're going to have every thread working on the same core which isn't very beneficial. From the snippets that Graham has given me so far I can see that you can make Apollo single threaded and multi threaded by simply changing a config file, he has 2 classes that execute player updating, ticks and reset, one class that just executes all tasks and another one that submits them into the parallel executor so Graham's framework has support for that.



    Reply With Quote  
     

  8. #18  
    Respected Member


    Join Date
    Jan 2009
    Posts
    5,743
    Thanks given
    1,162
    Thanks received
    3,603
    Rep Power
    5000
    Quote Originally Posted by Jimmy View Post
    But when multiple threads can be used to increase performance then why not use multiple?
    All the abstractions of multi threading could end up actually being slower then using a single thread. A good example of this is Hyperion which uses a great amount of concurrency in comparison to Runesource. However that doesn't mean it's bad, Hyperion can handle allot of abuse and stay within the threshold where as Runesource stays within the limit, however is effected allot more!
    Reply With Quote  
     

  9. #19  
    Registered Member Conner_'s Avatar
    Join Date
    May 2011
    Age
    27
    Posts
    464
    Thanks given
    198
    Thanks received
    40
    Rep Power
    29
    I personally just use a single thread for processing all the game logic, as well as 'services' that run asynchronously and contribute by doing two things:
    1. Submitting task objects to the task scheduler as needed
    2. Running their own ticks (the services), for example the world service ticks every 600ms and updates all entities

    The task scheduler runs off of a 10ms tick and never seems to have any problems.

    Whether or not that pattern is spectacularly organized, it works pretty well, so I can't complain

    It seems to me like people generally believe that more threads = better performance, but that's definitely not true (take into consideration the possibility of creating an entire thread for each entity!). Generally, it depends on the volume of tasks inputted to each thread and the way they're processed (and at what rate.)

    If you keep experimenting with different patterns with different variables as I mentioned previously you'll eventually find a pattern that works nicely for your server program.

    Reply With Quote  
     

  10. #20  
    brb ridin da storm

    blakeman8192's Avatar
    Join Date
    Dec 2012
    Age
    31
    Posts
    2,012
    Thanks given
    818
    Thanks received
    1,361
    Rep Power
    329
    I've found the most efficient design to be as follows:

    Networking
    All of this shit is single threaded. All of it. The system needs to get the job done as quickly and as simply as possible. Any thread pools added to the system will introduce the overhead of a queuing/dispatching system that is likely to use a lot of abstractions. When it comes to the networking, keep it simple. This is the reason why Runesource blows Hyperion out of the water in terms of performance, and is more than 10 times faster than even Grahams Apollo framework when benchmarked with 2,000 players.

    • Use the NIO libraries that Java 1.4+ provides. Although they may seem complex, with a little effort and some studying you can get it down. With a lot of experimenting and testing, you can master the NIO libraries. Anyone can do it, it just takes some effort
    • The simplest and most efficient design I've found is to do a select operation every 600ms at the beginning of each cycle, handling every packet immediately (down to the logic) and send data when you need to instead of using write readiness through the selector


    The above design has the following inherent beneficial characteristics:
    • Simple to implement, the networking system will just work without needing any tweaking
    • No packet queuing (this shows to be a huge performance gain) - all packets are handled immediately on the beginning of each cycle
    • Safe - game logic (as a result of packet handling) runs in a single thread


    The cons to this networking design are:
    • Incoming connections are only polled once every 600ms
    • Packets are handled only once every 600ms - this will not work for priority cache updating


    Some ways you can overcome the cons:
    • Accept all incoming connections on each cycle (call accept() until it returns null)
    • Use a separate thread dedicated to running a high-priority selector for accepting connections and for cache updating


    Player updating
    Here's where we get tricky with concurrency. Recently I took a version of Runesource and added thread-pooled player updating (it only took a few lines of code) and the cycle duration was cut down to one fourth of what it was without the thread pool - a 300% performance gain. As player updating is (for the most part) read-only, it's safe to thread pool it.

    The player updating procedure should look something like this:
    • For all players in the world:
      Dispatch a Runnable worker to the thread pool, which will:
      Synchronize on the player object and update them
    • Wait until all workers finish before returning


    The thread pool should have n threads where n is the amount of processors available to the system (which can be obtained by Runtime.getRuntime().availableProcessors()). It is important to synchronize on the player before updating them because modifications may be made to their local player list during the update process.

    Disk I/O
    This should also be asynchronous - either thread pooled or using NIO with a selector.
    It's important that the I/O should not block the main cycle, as this can cause unnecessary lag in-game.

    That's all, if anyone has any input feel free to post your criticism.
    rest in peace Qemist, Izzy, Colton, TeChNo PuNk, Impulser, & bootnecklad
    Reply With Quote  
     

  11. Thankful users:


Page 2 of 7 FirstFirst 1234 ... LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Replies: 32
    Last Post: 06-13-2011, 07:58 PM
  2. I fucking love concurrency
    By gnarly in forum Application Development
    Replies: 7
    Last Post: 02-16-2010, 05:22 PM
  3. Advanced Concurrency
    By blakeman8192 in forum Application Development
    Replies: 12
    Last Post: 01-31-2010, 07:05 AM
  4. What is concurrency?
    By Vastiko in forum Application Development
    Replies: 22
    Last Post: 06-03-2009, 02:45 AM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •