Hi Roland,

Each shared obj will be running in its own thread and will be calling methods asynchronously.

The main advantage is that long scripts will not freeze the main GUI thread.

Changing affinity pragmatically may certainly be of help under heavy load, but in general I would let the O.S. to take care of CPU pinning by itself.

Cheers,

Marco

The background threads will be running on the same logical cpu as the main thread so I'm not sure if you will see real improvement in performance.

You might be able to use the function SetThreadAffinityMask to assign each thread to a different cpu. I have not tried this so I'm not sure it will work.

I have used SetProcessAffinityMask to assign the entire process.

Long ll_hProcess = -1  // -1 = current process
ULong lul_paMask

// calculate the bit mask - note that cpu id starts at zero
lul_paMask = 2 ^ai_cpu

Return SetProcessAffinityMask(ll_hProcess, lul_paMask)

Hi Narayana,

yes, you can leverage Shared Objects for that.
- SharedObjectRegister allows to instantiate a PB NVO as a "shared" object (an object running in a different thread)
- SharedObjectGet —gets a reference variable to the shared object

—A method in the new thread can be executed asynchronously if called with POST, e.g. inv_shared.POST of_myLongProcess(...). Finally, if you need to send the results from the shared object to the main thread (usually the application), you must have the shared object to execute an "interface" object's method (a.k.a. "callback") and pass results.

In a nutshell (please refer to PB help):

1) SharedObjectRegister("nvo_shared", "share1”)
2) SharedObjectGet("share1", nv_thread1)
3) nv_thread1.POST myLongProcess(arg1, … , nv_callback)
4) nv_callback.POST display_values(val1, …)

Cheers,

Marco