boost up you game... (use multithreading!)

Here's a tiny example of implementing threads in you lite-c application.

download example (2.2MB)

But be warned!
Multithreading is not that easy to use and the syncronisation may be a challenge sometimes...

mercuryus

so CreateThread just... works? that's interesting, i haven't thought that lite-c was that much compatible to native c code.

The problems may accour in detail.
The cube-demo (multithread_crashes.c) works on my single-core system but crashes at the dualcore system. dunno why?

add a

while(key_t) wait(1);

after

if(key_t && gv_cubes<MAX_THREADS){

change in speed is magnificant, but idk if it reaaly worths it? (at least from my programmin skill level.)

there are things which should be calculated in their own threads, such as ai or network movement prediction.

Maybe it's possible to handle all particle effects in an separate thread or animations not need to be synchronised with gameplay (maschines/clocks/cloudes/fog/light/create dynamic content...).

But an extra thread is not "extra (so far unused) power" - a busy/overloaded thread can effect the main programm!

you can NOT use engine functions in other threads (especially every ent_, effect and _create function will probably lead to an crash). They'll crash randomly, probably because of sync issues

So I would restrict the use of a second or third thread on complex caculations like AI-Pathfinding.

Yes, things like pathfinding are a good thing to do threaded.

Hey TechMuc, what do you think about the safety of using the threads for
directx vertex manipulations and entity texture changes(ent_setskin)?

mercuryus thank you for this contribution.
Is multithreading integrated in Lite-c,I do not understand can I use multithreading in every system and any processor? Or multithreading may crash in some systems.

Quadraxas did you know is jcl testing multithreading on Lite-C?

But how about ditectx functions(d3d9.h), can I use this functions?

i just did quoted techMuc. you can read the rest of his message. he was talking about engines current state

Quadraxas on this forum easily confused

multithreading is a technique of the operating system (windows, unix, ...)
I can't speak for all types of systems/processors but every Intel(r) compatible prozessor (Intel/AMD) and all Windows(r) operating systems from Windows 98 support multithreading.

Since 3DGS only supports Windows(r) multithreading will run on every clients target plattform (with different performance).

But there is a difference between multithreading-support of the engine and lite-c!
The engine actually DON'T use multithreading but you're able to create multithreading applications with lite-c (see the example) yourself.

The main challenge of multithreading applications is the synchronisation of the results of the different threads but once your concept works well the benefit could be extensive (especially with the new generation of multi-core processor systems!)

I discovered that I/O-handling (file/video/sound) in more than one thread ends in a crash (and more!*) especial in multi-core-systems.


mercuryus


*) backup your system before playing with multithreading programming!

You can take a peek in windows.h in your gamestudio folder and see what other hidden miracles are available .

Multithreading is a must for calling a database realtime, if you don't want any stuttering. I think Lite-C simply ports it from your windows.h, together with alot of other useful functions.

Great contribution Mercuryus!

Regards,
Joozey

so with using lite-c functions for database in parallel, would I want to set up a global flag for data_locked, while the 2nd, nth threads are working, then get them to set it to unlocked when the database data is placed back into variables?

Is this the simplest sort of setup so that I can avoid crashes / mishmashed data?

(I'd think I would want multiple threads for database access, AI, network chat (reliable checks) and the like.)

Don
have a great day

You can only have a maximum of X many threads on windows systems. The default virtual space a thread consumes is 1Meg, and if you're not careful, your pc could end up being very busy for a long time. I suggest you create as few threads as possible, only use them when there's no way around, such as a database query. But even so you only need one extra thread for an unlimited amount of database connection. Pending queries may be stacked. I'm not sure what you mean with "data_locked", AFAIK you don't need to lock anything.

I guess I was thinking that when a 2nd thread was running an update query, I wouldn't want my main thread to be trying to read any of that data. I doubt I'll be using it in the very near future though, or without a bit more research. Thanks for the response

To gain the data in the main thread, you need to pass a pointer to the second thread to store the data in, then keep checking the pointer in the main thread for valid data.

G'day mercuryus. Sorry to resurrect an old thread, but your link no longer seems valid.

Is it possible for you to put the example up again?

Thanks,

Jibb

I cleared up my webserver (to free space).
Multithreading was downloaded too few in the last time - so I deleted it.

But I will put it on the server the next days again...

I think multithreading would be a good idea, but what about if one thread is busyier than the other, could glitches or "desync" issues occur?

@mercuryus: Thanks.

@CoburnDomain: One thread will generally be busier than the other. If it's the main thread, the secondary thread will probably just spend some time waiting for the main thread to be ready, but on a multi-core CPU that's still much better than having it all in one thread. If other threads end up being really busy (busier than the main thread) you'll either have the main thread wait for them (which really removes much of the usefulness of threading), or have the other threads notify the main thread when they're ready.

For example, if for some reason you needed an extremely expensive path-finding algorithm (it's not always about reaching a single position) you'd put it in another thread to avoid a pause whenever a new path is calculated. Each unit that requests a new path will continue what they were doing (or just wait) without pausing the main thread until they are notified by the secondary thread as to when they can move.

Or at least, that's my understanding. You'll still need to be really careful as to how the secondary thread will notify the main thread.

Jibb

download online again...

Many thanks!

Jibb

new download link

Isnt working

Stupid Google Chrome, will test it

Question?

I am correct in saying: The major benefit of multithreads is allowing a complex algorithm to run while also running the engine.

Would intermittent "wait(1)" commands in the algorithm perform a similar function?

Thanks

no, because the algorithm still eats the CPU time of the main thread

Partly if we talk a Pentium 4 CPU up to HT (single core), still it would stop the main thread run the other and then resume where it was. So technically it's the same but different.

Today most/all CPUs is multicore like Dual, Quad or i7 (8 cores) when kicking of a new thread this will take advantage of the cores still idle or low utilized (and run in parallel). Still the main thread will run at full speed so to say. Multithread make it possible to lift out heavy or slow processes from the main thread to run on an own thread and utilize the full potential of multicore CPUs if available.

Of course this also turn around how you program since you must make algorithms to take care of scheduling and keep track of all threads so you don't start to use results that still is not calculated or overwrite results that not yet has been used, but that is a totally other topic.

No, because the scheduler guarantees each thread X time units (probably microseconds, I don't know how the Windows scheduler works in detail).
When you spawn another thread, you have two times X time units (well, probably the second thread won't get the same time as the main thread and there is also the thing with priorities).

So, even with just one CPU Core you can still boost up your game by moving stuff into a second thread.

True, but to a cost for other running applications, OS core functions and services since there is still only one CPU to spread the workload on. My answer was a general on benefits from multithreading with multicore CPU since that is what most people have in their PC nowadays. Nitpicking on hardcore details was never my intention.

I remember reading that multi threads within GS are benificial when using them
multi media functions.

Are you talking about this thread: http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=341634#Post341634 ?
If so, this reads more like "we are using already multithreading for media functions" and not like "media functions would be faster if you knew how to spawn a thread."

Btw, not only media functions can be faster, everything that isn't time critical can be boost up. Eg. HTTP Requests or every other operation that uses the network should run asynchronously in another thread. Also Pathfinding could run in a second thread.

@JustSid Your right sorry about that.

As quoted from jcl: The engine itself can not use multiple cores because the main engine functions must run in a certain order.

But side functions, such as video or audio streaming, use multiple cores. You can also use them the way described above when you have time consuming functions.

so tracing wouldnt work in a new thread?