[Closed] MultiThreading in DotNet

Great stuff! If you wanted to use this to speed things up on a multiprocessor machine, how would you go about choosing a suitable number of threads? (assuming the task can be done with any reasonable number of threads).

Hi Neuro69,

each thread is run in a separate instance of the backgroundworker class. you can see this in the example, just bind each thread to a different task and it should perform them concurrently.

What I meant was, given a task that could be sliced into any reasonable number of seperate threads, how would one determine an optimal number of threads for any given computer/CPU? Preferably without hardcoding it?

Okay, I finally found (or made) an oppurtunity to try this, but I need to pass in array of structs…The problem is, whenever I try i get

>> MAXScript Rollout Handler Exception: – Runtime error: No method found which matched argument list <<

Here is the basic code…

	local theThread
			
	local dnmxv = dotNetMXSValue lstRollouts
			 
	theThread = dotnetobject "System.ComponentModel.BackGroundWorker"
	dotNet.addEventHandler theThread "DoWork" roPass.addPassRolloutsWorker
			 
	theThread.RunWorkerAsync dnmxv

Pointers, ideas, suggestions, all welcome…

Shane

hi shane, great to see you finding a use for this. one thought would be to put your ropass.addrolloutpassworker struct call into a global function and set the dowork handler to call that.

…to a point…

I’m still having issues when calling “BackgroundWorker.RunWorkerAsync(Object)” method using a dotNetMXSValue as the argument…although I’ve used the method in several other places (namely the ReportProgress and Result parameters).

This would suggest to me that max 9 does not have support for it

Shane

Hi Shane, In my drag and drop post earlier in the week we had an issue with dotnet value conversion between 2008 and 2009 so it wouldnt surprise me.

I tried the following in max 2008 and 2009. It does indeed throw an error when specifying the overloaded runworkerasync in 2008 but not 2009.

-- starting the overloaded background worker with a rollout 
 argumentobject  = dotNetMXSValue thread	
 if not MainThread.IsBusy do MainThread.RunWorkerAsync argumentobject
 	
 -- take the DoWorkEventArgs e variable and get the stored rollout dotnetmxs 
 Fn WorkThread sender e =
 (
 -- print the controls array from the rollout	
  print e.argument.value.controls
 )
 

so that is frustrating, but not the first example of what they have fixed between versions. Could you try calling a global struct instance containing the rollouts in the workthread instead of via the doworkeventargs argument??

Hay LoneRobot!

Yeah, I’ve basically had to set up global variable to play around with…not something I really want to do, but I don’t think I much choice…

Shane