Do gm games run on a single thread ?

[Xer0botXer0]

Hi guys,

So I'm trying to learn a bit more about the technical side of game maker and programming.

And I've stumbled upon threads, from what I understand by a game that runs on one thread is that as an example, when I move a player from x 10 to x 200, and Im also interacting with my inventory, I can see that the player is still moving, so it appears that it's running multiple threads at once, how ever since game maker 1.4 doesn't support multicore processing it means that it's running on a single core, but do single cores have multiple threads ? my guess is that they do but this article said they don't.

If game maker runs on a single core, and the assumption of it running on a single thread is true, then it means that my character is not actually moving at the same time as I'm working on my inventory, rather it's iterating between moving the character and then when Im busy with the inventory like I click on a button, gm picks it up and pauses the character movement to run the latest code, before returning to what it was doing.

In that regard I don't see a problem with it at the moment, but then as I read further along the article it's talking about how some single thread applications have to wait for lines of code to finish running before moving onto the next, Im guessing this is why game maker has asynchronous events, how then does game maker handle asynchronous events ?

I'm not sure where to discuss this type of topic, it's more of a how game maker works, which in turn will allow me to code better in some cases but does involve coding.

 

[GMWolf]

Gamemaker runs on a single thread.
But that does it mean you cannot do multiple things in a single step.
For instance, you can have multiple objects all moving "at the same time". What is really happening is that they are all being moved separately, one at a time. But it happens so fast you don't realize it.

This is the same for having a menu, but still other objects move in the background. Each step, you first update the objects, then the menu.

I think you may be forgetting tthat game simulations are not continuous, but discreet. Every step, you simulate a small amount of time, that runs once a frame.
If you run at 60fps, you would simulate (1/60) seconds every step.
So you never really pause the simulation for an okbject when a other apears.
Something like this happens every step.

foreach (instance in Instances){
 update(instance);
}

 

[Kenjiro]

To answer your other question. You can run as many threads as you like on a single core, but performance will become exponentially slower, due to time division multiplexing.

 

[Xer0botXer0]

Hmm it will become slower or rather more performance demanding ? Where if the CPU is fast enough to handle the extra performance required then running threads simultaneously would be useful.

I'm currently reading about thread-safety. Which is where from what I understand You prevent specific code from being read by separate threads simultaneously, so although you have multi threading they should not both read the same code block at the same time. Why I don't know, I don't think it's possible to read code at the same time but my guess is that if two threads pass by a code block simultaneously and the leading thread slows down a bit, the chasing one catches up and May over write the remaining data. Not sure if that's a problem I actually have to dive into it and if the problem comes up then see.

So then how does game maker handle asynchronous events I wonder. They are called asynchronous which implies they are not held back by other code. And run when need be. That has more to do with priority, that as soon as an asynchronous event is called it will run.. right after what ever code is being run has finished. Rather than run while other code is being run.

 

[GMWolf]

Async events are actually very syncrounous.

I hate it that YYG named them that way, because they do run serially. One after the other. Only during a step.

If an "async" event does get triggered, GM will essentially put it in a queue, and once a step, will dequeue and rrigger all the async events, one after the other.

 

[Kenjiro]

It's not even so much that the thread slows down if the same variables are accessed etc, it can (and very commonly does) cause 'deadlocks' which results in the program freezing. This is where 'mutexes' are used to 'lock' variables.

If thread A is using variable X, thread A should lock the variable. So if these B comes along thread B will stop if it tries to access variable X (which is what you want). It will resume immediately when thread A unlocks access to X.

In well written code locking and unlocking happens extremely fast, so as not to introduce stalling of other threads reliant upon the shared variables.

If nothing is shared between threads, there is no need to lock anything.

(Edit - fell666 got in before me, so my reponse is directed to the prior post)

 

[Xer0botXer0]

I read about this locking, I didn't know it can cause crashes.
I thought the second code would run through it too.
So when working with multi threading it's best to lock code and have the other code wait until it's unlocked. It said something about it being called 'monitoring'.

 

[Kenjiro]

Haven't heard the term 'monitoring' but yeah, sounds like a fair assessment.

Not sure if you can lock code as such, but definitely variables/data.

This seems to give a pretty good explanation as to what happens if you don't 'lock' things.

https://stackoverflow.com/questions/34510/what-is-a-race-condition

As for threading in GM, the only way you could achieve it is via a DLL. But, you still wouldn't be able to thread 'step events' etc as there is no way to access that kind of stuff under the hood. The best you could achieve is offloading what you need to thread entirely to the DLL, for example complex terrain generation. You could split the workload into 8 threads and send the result back to GM as a buffer. Theoretically getting 8x the performance that you would get if you did the same take in pure GML (i.e. single threaded).

In effect, you'll never be able to multi-thread GMS itself. But you can still get the benefits of extreme performance through multi-threading, if you plan the task carefully.

(Note: I use the term DLL loosely. When I say DLL, I include Dynlibs and SO's so as not to infer platform locking to windows. You can do this stuff on any platform )

 

[Joe Ellis]

is anyone thats having these kind of lags just really bad at coding?

anyway, the whole process of each gml code from each object gets executed in a linear fashion, from when each object was created, and from looking at the cpu usable can only get to 25% when the game is flooded and my pc has 4 cores, is definate its single threaded, you can expand to any amount of cores you want through an extension but native gml works on the 1st core

the asyncrous events are more of a reaction from various functions related to things outside of the game itself, ei loading a file, sending an email, interacting with an online server, this in no way means that its multithreaded

 

[zbox]

Re Async events - for all intents and purposes in Gamemaker, it just means "Call a function and don't lock up the game waiting for a result". So in that aspect it is asynchronous and what else would you want

 

[Joe Ellis]

but does it mean its multithreaded or single threaded, thats the key question here

 

[Kenjiro]

Hibba dibba da dibba do.

 

[GMWolf]

Re Async events - for all intents and purposes in Gamemaker, it just means "Call a function and don't lock up the game waiting for a result". So in that aspect it is asynchronous and what else would you want

Yeah, i guess in that respect, they are.
But the issue I have with it is that the events are called asynchronous, when it would be more accurate to say the functions are asynchronous.

Regardless, these sorts of functions will either run on their own frame, or there is a sort of state machine. I recall Mike saying once that GM did not make use of threads at all, so there is that. (Though, that does not seem right to me, networking for instance wph is be pretty poor if there wasn't a thread buffering all incoming data)

 

[Kenjiro]

Hibba dibba da dibba do.

 

[GMWolf]

With the network thing, no idea if it is threaded or not, but the underlying OS will buffer incoming data anyway. So, GM might not have to do anything fancy with respect to that. Not sure how many KB/MB the buffer is, I'd have to google that.

No idea though really, how GM handles this internally.

Well from my experience networking in kava and C#, using the standard linraries6, the function calls are blocking (meaning they will halt the thread until they receive something or time out). That means running them on their own thread is imperative.
I assume GM must have that on it's own thread.

 

[Kenjiro]

Hibba dibba da dibba do.

 

[GMWolf]

Yes, blocking sockets will stall flow if not threaded.

I haven't done any networking in GMS. Do blocking sockets not stall program flow in
GMS?

You don't have blocking sockets.
You only have async networking functions.

That is, the async event will fire when a message is received. You don't have to continually call a function to listen to the network. You just have to create the socket. It's all pretty simple.

Back to async: I guess actually it is a good name for them.
Whatbk don't like about it however is that it won't get called as soon as the event happens. It will I stead get buffered and executed sequentially.
Thi s caused a couple problems when I was trying to get some realtime audio generation and playback. But it's true that for most intents and purposes it's ok. (You just have to take the full frame of delay into account when measuring ping and such)

 

[Kenjiro]

Ah, ok. That doesn't really answer the question as to wether they are threaded or not, as the OS has three types of sockets - Blocking, non-blocking, and Asynchronous.

The asynchronous type are generally blocking sockets with callbacks from the message handler. This Is often done done single threaded, even though the underlying async sockets are generally blocking, this will not stall program flow.

 

[orange451]

Tried killing some threads. Seems there's one for game logic/rendering. One for sound. ect

 

[GMWolf]

Tried killing some threads. Seems there's one for game logic/rendering. One for sound. ect

Ahh Yeah, I remember Mike saying sound was on it's own thread. I should dig through the forums to find that post again...

Edit: found it!