Intertwining catch with posted events.

In the following I use the term “monitoring” to indicate that scripts are being executed as events are being recorded, while “testing” indicates that scripts are run after all events (except posted events) have been recorded. Monitoring and testing are kinds of execution contexts (for scripts).

As I understand it, “catch” statements do not themselves block indefinitely, whether the execution context is monitoring or testing, because there can always be a time out for “trying” the operation. This time-out is related to the actual time of running the script.

However, it may be that the time for “trying” can be omitted. (The wiki description of “catch” appears to allow omission.) In that case, there is always a window for looking for an event, and when the event board contains a span of relevant events whose overall duration exceeds the window value, the board will not be getting additional events within that window. So the board is window-complete for events of relevance and can time out, even if an event being caught is not present in the blackboard.

So it appears that whether monitoring or testing, a single threaded script execution environment will not block indefinitely because eventually the catch statement will time out for one of two reasons provided above.

While a “hang” of the thread remains possible (because looping is allowed), it does seem that a blocking hang will not be a problem for single threaded execution environments because of catch.

However, adding the posting of events to communicate between scripts can create issues for multi-threaded environments.

Suppose thread A has catch A that is waiting for an event that can be posted from a script running in thread B. Thread B could have its execution delayed so that it fails to post an event before thread A’s “trying” time out arrives. In that case thread A misses the event from B that it was to catch. [The multi-threading introduces a kind of indeterminism into the outcome of the script execution for situations involving post of events.]

But why would this “missing the event” impact multithreaded and not impact single-threaded execution environments? If the sequence of instructions in thread A is run before all instructions of thread B, and A is waiting for an event that will be posted by B, then A will have finished before B runs and not see the event B posts. Presumably no one would write a script that waits for an event that only can be produced after the script finishes! So the single-threaded case is categorized under “silly user error is always possible”!

Back again to multithreaded execution environments-- how can threads be synchronized appropriately so that when posted events can be produced by a separate thread, a thread waiting for such “synthetic” events does not complete until the other posting thread has completed? I think it will take some more investigation to see how to use posting events to coordinate script actions in a multithreaded environment so that various race conditions do not produce unexpected results.

A simple example and the start of an analysis from the Event Processing community (EP or CEP) can be found at:

http://epthinking.blogspot.com/2008/10/more-on-semantics-and-race-conditions.html

tamie message