Basically, the problem is that salience doesn't mean much in a
multithreaded system. A rule may have very low salience, but if it is
activated before other rules of higher salience are activated, then it
may be fired (on the run thread, different from the thread where the
rule was activated) before those other rules have a change to displace
it from the top of the agenda.
In this case, your low-salience delete-timer-events rule is firing as
fast as the new facts appear, before the quarter-minute and minute
rules have a chance to fire. delete-timer-facts matches every
temporal-event fact as soon as it appears, and furthermore, the
patterns are identical to those of the rule show-seconds, so both of
those are being activated together, and salience makes show-seconds
fire first. But the other two rules have slightly different patterns,
so they're activated at a slightly different time (the order here is
arbitrary and, as you've seen, depends on the order in which the rules
are defined.)
One more definite solution, rather than yours which depends on
undefined behavior, is to modify delete-timer-facts so that it allows
a few timer facts to stay around before deleting them -- i.e.,
something like
(defrule delete-timer-events "Delete any old temporal-event facts"
(declare (salience -100))
?t <- (temporal-event (ctm ?ctm))
(not (temporal-event (ctm ?ctm2&:(> (- ?ctm 1) ?ctm2))))
=>
;;(printout t "Retracting " ?t crlf)
(retract ?t))
Now, the underlying Jess behavior that causes this is something we've
talked about on the list before. Basically, what Jess does now is
allow rules to initiate firing on one thread during pattern matching
occurring on another thread; if a single fact activates three rules,
then the first activation can fire before the second rule is even
placed on the agenda. This has very good liveness characteristics, but
leads to inversions like what Mitch is seeing here.
An alternative is for the agenda to be locked during pattern-matching,
so that the run-until-halt thread would not be able to pop an activation
from the agenda until after all the activations from a single
assertion event were present. This would make Mitch's problem go away,
but with a potential performance loss in densely multithreaded
operation.
Anyone want to comment?
I think Mitch Christensen wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hey,
>
> I'm having trouble understanding why reordering 'defrule' statements in a
> Jess script changes how the program runs.
>
> Specifically, I've created a UserFunction timer that asserts a
> 'temporal-event' fact every second (source attached). Then I have a simple
> Jess script (also attached) that loads and executes the UserFunction, and
> then defines 3 debugging rules. These rules do a printout at each second,
> quarter-minute and minute (there is also a rule to retract old facts).
>
> My problem is that the seconds rule always fires, while quarter-minute and
> minute rules are sporadic (sometimes they fire sometimes not). If I simply
> re-order the rules, putting the minute rule first, the quarter-minute rule
> next and the second rule last, things seem to work fine.
>
> Now, if I understood why, I'd be in pretty good shape. ;)
>
> Any suggestions?
>
> -Mitch
>
> P.S. 'ctm' is for CurrentTimeMillis. It's the only way I could find to keep
> rules from firing more than once, i.e. "only fire if this fact has the
> lowest ctm in working memory" and to fire in the proper order should
> multiple temporal-event facts be asserted between (runs).
>
[Attachment, skipping...]
[Attachment, skipping...]
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://herzberg.ca.sandia.gov
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
