What's with multithreading?

[L B]

I'm trying to create another thread for my network operations.

This thread uses an infinite loop in which the client waits for data.

 

Whenever I use the thread, I get a major slowdown on my main screen (-10 to -15 FPS), but nothing happens in the loop (it's a blocking method, so nothing happens until I receive data).

 

My question is, why does another thread even affect my main window? Is there any kind of block or unknown mechanism?

 

EDIT: Been trying millions of ways. Whenever you throw a new thread in, beware the massive, huge lag. I wonder how I'm supposed to do my networking.

[Josh]

Are you using Leadwerks network commands, or something else?

[L B]

Something else. I use my own second thread. In C#, it's System.Thread, couldn't be more basic than that. I really need this.

 

I even tried a async (non-blocking) method, so that works "well" when there isn't any data received. However, when data gets received and a background thread gets created to handle it, the FPS lowers by 10 FPS.

 

Any multithreaded operation seems to immensely lower FPS. This has been reported by other people trying to handle loading with another thread. Although their loading process worked, it created a major graphical lag, same as this.

 

It seems to me that Leadwerks tries to handle any multithreaded operation in its main thread, with a timeout when a blocking operation occurs. [/theory]

[Josh]

The engine does not control your threading. If the engine is running on one thread, you can do anything you want on another one, as long as it isn't simultaneously calling the engine commands.

[Rekindled Phoenix]

Is there any way for two or more threads to easily call engine commands?

 

Let's say I have one thread in a render loop. If another thread that manages AI needs to check entity visibility using raycasts, how should that be done without 'locking' the main thread?

[Masterxilo]

That's not possible.

You can't execute multiple leadwerks engine commands simultaneously.

[VicToMeyeZR]

The engine does not control your threading. If the engine is running on one thread, you can do anything you want on another one, as long as it isn't simultaneously calling the engine commands.

 

 

So LE isn't multi-threading capable?

 

Trying to run networking on another thread is going to access the engine commands. You have to pull positional data to send via networks.

[Rick]

I think how that works is that the network thread is thread safe so that you can access that data in your LE thread. That's how it works with RakNet at least.

[Rekindled Phoenix]

I think Josh has made the networking code thread-safe. It used to be in a separate DLL as an abstract layer to the LE API.

 

OpenGL seems to only respond well to the process' main thread for engine commands (excluding networking) when it comes to C# / VB. If another thread calls graphics commands, it's ignored or the application throws an exception.

 

Can anyone else verify that I'm correct?

[VicToMeyeZR]

 

EDIT: Been trying millions of ways. Whenever you throw a new thread in, beware the massive, huge lag. I wonder how I'm supposed to do my networking.

 

 

Are you using reference pointers to get the data you want to send via networks? You shouldn't use the network library to actually run an engine command, just make sure its a pointer to the variable you want. That should work.

[L B]

I made a method queue for transmitting. My second thread transmits a method to the first one (LE), and the first one dequeues it at every loop^, executing the command.

[VeTaL]

Just a supposing: is it a good idea to run in another thread a level loader, so game would be looking like huge world ?

 

For example, separate all world on cells and load models of 9 cells: player is in the middle one, and 8 cells around him (cell is a large level). And when player moves to another cell, unload 3 old cells and load 3 new.

I'm afraid that without loading levels in second thread, it would be noted by user.

[Rick]

I made a method queue for transmitting. My second thread transmits a method to the first one (LE), and the first one dequeues it at every loop^, executing the command

 

Could you explain this more? I'm not following, because that really wouldn't be getting the entire benefit from multi-threading since the LE thread is still making all the calls.

[L B]

Just a supposing: is it a good idea to run in another thread a level loader, so game would be looking like huge world ?

 

For example, separate all world on cells and load models of 9 cells: player is in the middle one, and 8 cells around him (cell is a large level). And when player moves to another cell, unload 3 old cells and load 3 new.

I'm afraid that without loading levels in second thread, it would be noted by user.

Not possible. This requires making LE calls, so it would all end up as if it was the main LE thread doing it, or it would crash. Don't bother trying to make multiple threads for that, just use the main one. Still, accessing objects across worlds is not possible at the moment.

 

Could you explain this more? I'm not following, because that really wouldn't be getting the entire benefit from multi-threading since the LE thread is still making all the calls.

I could explain, but in C#. Tell me if you want, I'll PM you.

[Rick]

I could explain, but in C#. Tell me if you want, I'll PM you.

 

That's fine, I work in .NET all day long at work. From what I can see you are adding LE functions to be called in one thread and actually calling them in the LE thread. If so that's not really getting the benefits from multi-threading.

[L B]

LE can only process actions once every loop - just as any engine would. The point of my use of multithreading is of allowing other threads to tell LE which actions to execute at the closest possible loop, a.k.a. almost instantly as we are talking about fractions of fractions of seconds.

[Rick]

LE can only process actions once every loop - just as any engine would. The point of my use of multithreading is of allowing other threads to tell LE which actions to execute at the closest possible loop, a.k.a. almost instantly as we are talking about fractions of fractions of seconds.

 

Yeah, but you aren't really saving anything or gaining any of the benefits that threading gives. Some engines allow you to call engine functions on separate threads. So that calling a load of an asset doesn't pause your main thread, which is what happens in LE and still in your system you have. That's the main issue to try and solve.

[L B]

I'm not interested by that extra-detailed load function yet as many of the users seem to be now. However, the other thread can make all the calculations, analysis and data exchange, and then simply tell the client what to do. That's my vision of multithreading advantages. You're asking for a progress report on the loading function and for locking the main thread. It's really simple to call engine commands from another thread - I did. There isn't any limitation. But you'll lose a frame in the process while you have to lock it.

[VicToMeyeZR]

You should be able for, I would say 90% of any networking that you need, use pointers and de-referencing to get and set any information you need. You wouldn't need to call any engine commands for most of what you need.

 

Least that's what I am thinking for the networking. All that data is stored in memory blocks, and if your using engine commands to set those, then you are losing all those frames, and if your doing that for 30 players.....

[Canardia]

LE uses already multi-threading:

For graphics rendering it uses 128 GPU cores plus 1 CPU core. Then you have 3 CPU cores left, which you can use for disk I/O, network I/O and web camera I/O. Now you have all 132 cores (QuadCore+GeForce 8800) in use. CPU cores are slow, so you should avoid them and use GPU cores as much you can.

[Rekindled Phoenix]

Using any amount of GPU cores is not the same as a multi-threaded application. It's not the GPU cores that Ubu cares about, its the amount of threads per process that he can use in code to take advantage of the Leadwerks Engine. Lumooja, are you confusing cores with threads?

 

The thread that initializes the Graphics Window is the only one that can make engine calls. Ubu and Rick, am I correct on this?