PDA

View Full Version : Thread Synchronisation


kogen
01-29-2009, 05:28 PM
Hey guys,

I'm having a little problem, and I hope some of you might have a solution or even just an idea:

I have a little Max Script that reads a couple of values from a file. Everything would be fine if there wasn't another application (VB) that is constantly overwriting this file. To be more precise: Max Script reads a value every second. The application in VB overwrites theese values every second. So Max-Scripts reads out the new values one second later, and so on and so forth. The problem about it is, that Max script or VB becomes sometimes a tick faster/slower which results in an error because max script tries to read out data in a moment where the file is empty.

My question is: Is there any chance to create thread synchronisation between those two applications in Maxscirpt?
I'm thinking of something like: If MaxScript reads the file, VB can't write, but if VB writes, Max-Script isn't allowed to read?

Thanks for your help.

Cheers "ko'gen".

Piflik
01-29-2009, 05:45 PM
Are you sure you have to do it that way? I would assume that this is highly unstable, even if you get it to work correctly, and as far as I know there is no option in MXS to prevent another app to edit external files or check if a file is edited by another app.
There might be a different way to do it (if we had more information on what you need to be done).

kogen
01-29-2009, 06:48 PM
Actually this is everything that needs to be done: One application creates a couple of values, let's say integer values. And theese values need to be passed to 3D Studio Max every second. So another way would be to let this application pass values directly via a String stream that is located somewhere in the operating system. But actually that's even more complicated than having a file that works as a link between those two apps. It would be great if no file was needed and if I could write those values directly in an array in Max Script, but, I guess this isn't possible at all.

Piflik
01-29-2009, 07:07 PM
So you need these values in Real-Time while the script is running? What are these values? Can you maybe leave out the external app and create the values directly within MXS?

kogen
01-29-2009, 07:40 PM
Realtime would be the top of the iceberg ;) . I'd be glad if they could be read within one second.
As I said the values are simple integers (at the moment). And unfortunately I can't create theese values in Max script. (Yes I could create a file with another Max-script containing random values, but this would make no sense). Because the other application reads the values from a temperature-sensor. So I'm forced to work with it. As I said it would be cool if I could access this sensor via Max script, but I don't think that's possible.

Bobo
01-29-2009, 07:51 PM
Realtime would be the top of the iceberg ;) . I'd be glad if they could be read within one second.
As I said the values are simple integers (at the moment). And unfortunately I can't create theese values in Max script. (Yes I could create a file with another Max-script containing random values, but this would make no sense). Because the other application reads the values from a temperature-sensor. So I'm forced to work with it. As I said it would be cool if I could access this sensor via Max script, but I don't think that's possible.

What I would do is this:

When Max reads the file, it also stores the last modified date of the file. Then at its next attempt to access the file, it would check if the date has changed and if it has not, it would wait and try again some milliseconds later.

Or you could create a LOCK file with your VB application while the data is being written and delete it once it is done. MAXScript would check if the file is there and only read the data if it is not there. MAXScript could also write its own LOCK file while reading and the VB app would wait for it to disappear before writing its data.

Or you could pass the data via DotNet...

kogen
01-29-2009, 08:34 PM
Thanks Bobo,

the LOCK-file sounds like a good method to start with. I also like the idea of the check-variable. Right now I've included a statement like: if the file is eof right after opening then the clock timer "waits" a couple of milliseconds and tries again later. I'm a little bit confused, cause there's only this "wait" statement in Max Script which holds on the whole system. Is there something else that let's you still work in Max while waiting?
Anyways Dot-Net is an idea but it would take me weeks or even months to learn all the new commands, so I'd like to stick to MXS.

Thanks

- "ko'gen"

vScourge
01-30-2009, 03:16 AM
A file-free option could be to use COM. Create a simple OLE/COM server in MaxScript, then connect to it in your VBScript and send the values in every N seconds. The MXS side can stuff the values into a global array or something, for your script to use when needed.

I haven't tested this, but something along these lines:

In MaxScript:
fn passVBValues value1 value2 = (
global vbVals = #(value1, value2)
)
registerOLEInterface #(passVBValues)

Then in VBScript:
MXSObj = WScript.CreateObject("MAX.Application")
MXSObj.passVBValues(value1, value2)

If you needed the MaxScript to do the timer part, you could reverse the above, with the VBScript creating the server for MXS to connect to, using createOLEObject instead.

kogen
01-30-2009, 08:04 AM
Wow, I'm excited how many interesting solutions there are. I thought there might be only one answer: "No".
Thanks for the hint vScourge I didn't know, MXS is able to work with such kind of "individual files" like excell. There was only one problem, when I read the user reference.

The server application that was attached with createOLEObject() is released and terminated when the created MAXScript OLE object is eventually garbage-collected. You can explicitly disconnect from an OLE server application with the releaseOLEObject() function.

and this:

OLE AutomationAfter calling this function, all existing OLE objects become disabled and any attempt to use them further will generate a runtime error.




This seems to me that you can only access the application once and after that you'll get the runtime error?

vScourge
01-30-2009, 12:00 PM
The first item just means when your OLE object falls out of scope and is garbage collected by Max, that OLE interface can no longer be used until you create it again. This is no different than any other variable you define that gets cleaned up later. If you find this happening in your tool you can just make that object global.

All the second item means is when you call registerOLEInterface <array of functions>, it clears out any prior interfaces you've made in that Max session. If you've never created or used any others, it doesn't matter.

kogen
01-30-2009, 03:58 PM
Ah, I see. Thanks again for your explanation. I guess I'll keep this method in mind. Today I tried it with the Lock-File and it seemed like the script was working (there was no "Read after filepos"-error for around five minutes ;) ) But maybe I'll need the interface method if there will be more computers trying to write in that file.

Thanks again for the great and fast help, everyone.

CGTalk Moderation
01-30-2009, 03:58 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.