Zugg Software :: View topic

Posted: Thu Dec 06, 2007 2:47 pm

Now that the threading system has been pretty well tested, I am making a big change/optimization in v2.15.

In v2.15, CMUD will check to see if you are using #WAIT commands (#WAIT, #WAITSIGNAL, #WAITFOR, #WAITTHREAD) or the #THREAD command (with parameters) or the #SUSPEND command. This check is done when something is compiled (like the command line, or an alias, trigger, etc).

If the script does *not* use one of these threading commands, then the script is executed in the main UI thread without creating any thread object.

This causes a big performance boost for most scripts since they are not running in a separate thread and, therefore, do not need all of the overhead to synchronize various non-thread-safe commands with the main thread.

This should allow most threads to run at the same speed that they did in v1.34 before threads were added. But it still allows proper use of the various #WAIT commands that were added in v2.x. The best of both worlds.

To force a script to run in it's own thread, use use the '#THREAD name' command to name the thread. This might be needed if you are doing something really obscure like running #WAIT within an #EXEC command.

I have been thinking about this kind of optimization for several months. But I only wanted to add it right before the public release so that we could really stress-test the threading system. If I had added this several months ago, then most people wouldn't have used threads and we wouldn't have gotten the testing that we really needed to make CMUD stable.

Posted: Thu Dec 06, 2007 3:51 pm

Very nice. Although now I'll have to really do some thinking before I choose to implement any threading functionality in my scripts. I'll have to make sure any benefit I gain from multi-threading will outmatch the slowdown that will occur by adding it. I guess once you have it in we'll be able to see the magnitude of the difference. In general I'd want to move toward some type of threading in my scripts to take advantage of additional processors, but this will make it very seductive to have it all one thread.

Posted: Thu Dec 06, 2007 4:39 pm

The slowdown is pretty minor, so I wouldn't let that keep you from using threads when you need them.

Apprentice Joined: 26 Apr 2007 Posts: 113

Who feels conned? >.>

In seriousness, this is a great change, Zugg. I can only guess how many complaints we had against multithreading because of the problems that came with it.

Posted: Fri Dec 07, 2007 3:55 pm