GameMonkey Script

GameMonkey Script Forums
It is currently Thu Jun 27, 2019 8:20 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: thread priorities
PostPosted: Mon Feb 19, 2007 6:52 am 
Offline

Joined: Fri Nov 24, 2006 9:50 am
Posts: 165
Hi there, is there any support for running threads in a particular order?
I need some threads to run before others.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 19, 2007 7:54 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 708
No such feature exists. The current work around would be to insert Sleep or Block thread functions into your script.

I don't see why you could not add this feature by modifying gmMachine::Execute, storing a priority value in gmThread. You'd also bind a function to set priority on a thread. I must admit, it would be nice to detach threads from the gmMachine and execute them manually and individually. I would never recommend modifying gmThread::Sys_Execute() to do instruction based scheduling. That would change threads from coop routines into preempted style threads introducing all the pain of OS threads. I'd only modify the 'user break callback' section to terminate endless loop threads based on some metric.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Feb 19, 2007 8:30 am 
Offline

Joined: Fri Nov 24, 2006 9:50 am
Posts: 165
Yup, I am going to go ahead and add this then - I was just double-checking in case there was an inherent system already implemented. I don't want pre-emptive threading tho, just the ability to have a running order, or maybe even call, say, all threads of a priority lower than 128 before "drawing", and the rest afterwards. I might simply implement it as a grouping of threads, so you can have "pre-draw" threads and "post-draw" threads and "during-draw" threads etc.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Feb 21, 2007 2:23 pm 
Offline

Joined: Fri Nov 24, 2006 9:50 am
Posts: 165
ok, I've made the modifications to do priority based threading without any speed impediment: It makes gmMachine a little larger but seeing as there is only one of those it's not much of an overhead.

If I post the diffs could you take a look Greg, I think it's worth including in the main version as there is no speed or size change (apart from gmMachine).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 22, 2007 8:14 am 
Offline

Joined: Fri Nov 24, 2006 9:50 am
Posts: 165
Here is a zip of the patch file,

The priorities are implemented simply by changing m_runningThreads to a 256 entry array of DoubleLists, one entry per priority. Then it was a simple process of going through the 5 or 6 accesses of m_runningThreads and making them loop over all priorities where necessary - or using the thread's priority to insert thread's into the correct m_runningThreads.

I added one byte to gmThread, which, because the last member was a short anyway doesn't affect the size of gmThread as on most machines it is rounded to 4 bytes or more. (and a GetPriority and a Sys_SetPriority "internal" function)

I also added default parameters to Execute() that by default will simply execute all the threads in priority order, but if you like you can specify a range of priorities for it to execute.


Attachments:
threadpri.zip [3.58 KiB]
Downloaded 406 times
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 22, 2007 8:35 am 
Offline

Joined: Fri Nov 24, 2006 9:50 am
Posts: 165
I forgot to mention, from gamemonkey a thread's priority is set like this: - setThreadPriority( [thread_id] ), it will return you the old priority and set the priority of the current thread if no args are given. getThreadPriority( [thread_id] ) will also give you the current thread's priority or the priority of the thread specified.

If you change your current thread's priority multiple times in a positive direction you can get your thread to run multiple times in a frame, and if you decrease the priority the thread will run the next frame.

Patching this requires no changes to existing code, and incurs no speed difference. Memory-wise there are 255 more nodes created for the array of DoubleLink lists, but unless you create hundreds of gmMachines (not a good idea anyway) that won't affect you.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 22, 2007 11:13 am 
Offline

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 708
Thanks for sharing that HiVision. I see you have gone with thread grouping and manual execution order. 255 slots seems quite a range to trawl through each frame, though likely insignificant for modern machines. I'd be interested to see alternative scheduling methods that don't require time consuming sort operations, but still throttle execution effectively.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Feb 22, 2007 12:05 pm 
Offline

Joined: Fri Nov 24, 2006 9:50 am
Posts: 165
It's not so much a grouping of threads as a hashing of the priorities, but it can be treated as grouping too (hence the modification to the Execute command).

The no. of slots and default thread priority could be set or overridden in the Config file for smaller less powerful machines. In reality a smaller no. is perfectly alright. Even a no. as small as 10 would be extremely handy.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group