Behavior of Threads in Client Timer Event Script

Ignition
,
1

I am currently working in a pretty archaic system, that is using a client event timer script at 50 ms to call the main() function in the scripting module. Currently there is no thread safety to this procedure and is leading to multiple race conditions, the main function calls 12 other scripting modules that provide separate functionality.

I’m wanting to know what happens when the main() function is called from the client event script. For example, is the Scripting module being recompiled? Does the JVM kill the existing threads? Or do threads stack up in the background every time the main() function is called, and all processes aren’t completed?

So far, I have noticed that local variables are re-initialized on each call, however, I’m not sure about if the threads are removed.

For reference, it takes on average 40 s for a “real loop” to be finished, however, the script is running at 50 ms and the tags for the system are updated every 100 ms.

My second question is that I am looking into using daemon threads for logging as it currently stands, logs are clogging up operation. Will calling the function again from the client event script garbage collect the daemon threads?

2

No, neither of these.

No. The behavior depends on whether it's fixed delay or fixed rate, but:

Only one instance will be executing at any given time.

3

Sounds like there's a use of system.util.invokeAsynchronous(), if you really have multiples running together.

4

Okay that is perfect, it is running on a fixed delay with shared threading. If I’m understanding correctly no matter whether or not the script has finished it will be restarted from the top every 50 ms. Will this cause overlapping behavior?

5

No, you're not understanding.

The script will run to completion, however long that takes, and then will start again immediately if "however long" was longer than 50ms.

6

I think this would work well with some of the background functions, thank you!

7

This means that there will be a 50ms pause in between runs, no matter how long it ran, and all other shared threading timers will also not run when it is running.

1 Like
8

Okay, that makes sense.

9

Oh, yeah, I read that as "fixed rate" for some reason.

So: the script will run to completion, however long that takes, and then will start again 50ms after completion.

1 Like
10

Perfect, thank you!

11

I would caution against adding invokeAsync and new Threads. You may have lucked your way into inheriting something that is slow but "safe" right now.

If you start spawning new threads and speed up the main script you may actually end up in a situation where you start to accumulate slow running async threads and run yourself out of memory or just experience inconsistent behavior / race conditions. Without significantly more info it's hard to say.

3 Likes
12

I wouldn’t say it is “safe” right now mostly due to overlapping DB queries sniping data from each other. I might be looking for some mutex functionality to make sure things happen in order. On each call of the client event script do the local variables of the Scripting module reset or do they persist?

13

Yeah, there be dragons. The task must be doing waits for various things in a procedural sense. It needs to be analyzed and redesigned to operate in an event driven manner (typically as a state machine), so that all events run without blocking. (Handful of millis at a time.)

14

Persist. Anywhere you might be getting simultaneous access needs locking (for your algorithms). Unlike CPython, Jython is fundamentally multi-threaded. Basic building blocks like dictionaries and lists are thread-safe, but algorithms built with them typically are not.

1 Like
15

Thank you, I’ll be able to work with this.