Send information from other thread, to Unity's main thread

[allencook200]

How would I do this? Would the only way, just be to use a ConcurrentQueue and poll for new entries in update()?

My other threads are running a bunch of TCP connections for my clients.

[Bunny83]

@allencook200

Would the only way, just be to use a ConcurrentQueue and poll for new entries in update()?

Well, you don’T have to use a ConcurrentQueue, however the answer is essentially yes, you need a thread-safe way to access it from the main thread. Keep in mind that a thread is just an execution context that runs sequential code, opcode by opcode. You can not simply insert code from outside into a thread. So you generally have code that runs inside that thread which needs to read external information. This can even be a lambda expression that is executed on the main thread. Though you need some code on the main thread that does this for you.

Any application, as seen from the operating system, has a main thread that is in the end just a while loop that is running in circles. The main loop of a Unity application is owned by the Unity core itself. At certain points Unity calls your code like the Update methods for example. Once your method is done, Unity’s main thread will continue. Note that most desktop applications are event based. Though they still have a main loop. They just query the next message from the threads system message queue. If there’s no message the thread will essentially sleep until the OS puts queues a message for the thread- Mote real time applications (using Windows as example) do not call GetMessage as this would block the main thread until a message is available. Instead they just use PeakMessage to consume any messages which may be waiting and otherwise just run cycles which we call frames.

So in order to process data or code on the main thread, that data need to be read from code in the main thread or the code that should be executed need to be called from the main thread.

So in short, yes you need to process that data in Update and make sure you stay thread-safe. Note that thread-safety does not always require a lock or a thread-safe collection. Though it depends on the exact usecase. So a pure single producer and single consumer scenario could be done lock free. However reading things once per frame and securing this through a lock isn’t that expensive. Especially for network communication, the sendrate is usually even lower than the visual framerate-

[allencook200]

@Bunny83

Well, you don’T have to use a ConcurrentQueue, however the answer is essentially yes, you need a thread-safe way to access it from the main thread. Keep in mind that a thread is just an execution context that runs sequential code, opcode by opcode. You can not simply insert code from outside into a thread. So you generally have code that runs inside that thread which needs to read external information. This can even be a lambda expression that is executed on the main thread. Though you need some code on the main thread that does this for you.

Any application, as seen from the operating system, has a main thread that is in the end just a while loop that is running in circles. The main loop of a Unity application is owned by the Unity core itself. At certain points Unity calls your code like the Update methods for example. Once your method is done, Unity’s main thread will continue. Note that most desktop applications are event based. Though they still have a main loop. They just query the next message from the threads system message queue. If there’s no message the thread will essentially sleep until the OS puts queues a message for the thread- Mote real time applications (using Windows as example) do not call GetMessage as this would block the main thread until a message is available. Instead they just use PeakMessage to consume any messages which may be waiting and otherwise just run cycles which we call frames.

So in order to process data or code on the main thread, that data need to be read from code in the main thread or the code that should be executed need to be called from the main thread.

So in short, yes you need to process that data in Update and make sure you stay thread-safe. Note that thread-safety does not always require a lock or a thread-safe collection. Though it depends on the exact usecase. So a pure single producer and single consumer scenario could be done lock free. However reading things once per frame and securing this through a lock isn’t that expensive. Especially for network communication, the sendrate is usually even lower than the visual framerate-

Perfect answer, thanks

[mgear]

i’ve been using this,
“A simple, thread-safe way of executing actions (Such as UI manipulations) on the Unity Main Thread”

GitHub - PimDeWitte/UnityMainThreadDispatcher: A simple, thread-safe way of executing actions...

[allencook200]

@Bunny83

Well, you don’T have to use a ConcurrentQueue, however the answer is essentially yes, you need a thread-safe way to access it from the main thread. Keep in mind that a thread is just an execution context that runs sequential code, opcode by opcode. You can not simply insert code from outside into a thread. So you generally have code that runs inside that thread which needs to read external information. This can even be a lambda expression that is executed on the main thread. Though you need some code on the main thread that does this for you.

Any application, as seen from the operating system, has a main thread that is in the end just a while loop that is running in circles. The main loop of a Unity application is owned by the Unity core itself. At certain points Unity calls your code like the Update methods for example. Once your method is done, Unity’s main thread will continue. Note that most desktop applications are event based. Though they still have a main loop. They just query the next message from the threads system message queue. If there’s no message the thread will essentially sleep until the OS puts queues a message for the thread- Mote real time applications (using Windows as example) do not call GetMessage as this would block the main thread until a message is available. Instead they just use PeakMessage to consume any messages which may be waiting and otherwise just run cycles which we call frames.

So in order to process data or code on the main thread, that data need to be read from code in the main thread or the code that should be executed need to be called from the main thread.

So in short, yes you need to process that data in Update and make sure you stay thread-safe. Note that thread-safety does not always require a lock or a thread-safe collection. Though it depends on the exact usecase. So a pure single producer and single consumer scenario could be done lock free. However reading things once per frame and securing this through a lock isn’t that expensive. Especially for network communication, the sendrate is usually even lower than the visual framerate-

What if I use the unity jobs system to create an API-usable thread to handle retrieving and processing from the Queue? Would that be reasonable?

Can’t use jobs for the TCP threads because I need to be able to spawn them on-demand