Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

NetworkTransport.Send & threads

Discussion in 'Multiplayer' started by Whippets, Jun 25, 2015.

  1. Whippets

    Whippets

    Joined:
    Feb 28, 2013
    Posts:
    1,775
    I've got a multithreaded server; quite common to fire off a thread to deal with a database query or do some hard sums, so it doesn't slow down the main thread. But a pain when that thread wants to Send() it's result back to one or more clients.

    Is this likely to be looked at in the future, or are we stuck with single threading for good?
     
  2. aabramychev

    aabramychev

    Unity Technologies

    Joined:
    Jul 17, 2012
    Posts:
    574
    We are working on server lib, but i'm sure there will not any implicit locking inside. The reason: different user design and implementation will require different locking strategy... Imagine I added implicit lock to the send, and receive following request: "Dear developer, I spent a lot of time working on performance my server code, after all I did it lock and wait free, so it is super fast now, hence I found that Send() function call mutex.lock inside which is quite slow operation, could you remove this code..." What we need to answer? :)

    So I think it is much better to leave locking strategy to developer. Isn't it?
     
  3. Whippets

    Whippets

    Joined:
    Feb 28, 2013
    Posts:
    1,775
    Yep, it's good to leave the locking strategy to the developer, but I don't see anything to lock, to enable me to use Send() from a separate thread. If there was something I could lock to use Send, I'd be happy with that.
     
  4. aabramychev

    aabramychev

    Unity Technologies

    Joined:
    Jul 17, 2012
    Posts:
    574
    hmmm, I don't know is it good idea or bad:) It is probably because, actually, I don't understand what is prevent you to create your lock for send()? Is it because you use HLAPI and LLAPI together?

    If you can call Send() directly, you can add mutex to this call, correct?

    Anyway, what I can promise that we will take into account your suggestion when we will make decision :)
     
  5. Shinyclef

    Shinyclef

    Joined:
    Nov 20, 2013
    Posts:
    505
    Yes you don't need something internal exposed for locking, as you can lock on anything you want. Create a method that all your threads can access, and place the send() call inside a lock, using an object of your choosing as the lock.

    Then just direct all your send() calls to that method.
     
  6. Whippets

    Whippets

    Joined:
    Feb 28, 2013
    Posts:
    1,775
    ty all :) What I'm using for now is a Queue which is processed regularly. All Sends() are put on the Queue from whatever thread, and the main server loop which does the Reading, now also handles the Send()ing