Sorry to revisit this issue but I had a couple of comments. See below.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 8:12 PM
To: [EMAIL PROTECTED]
Subject: Re: JESS: Defrule ordering woes
<snip/>
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?
[alan]
Could you selectively lock the agenda on a per-assert basis by having the
thread asserting facts be able to run a "transaction" during which the
agenda is locked?
This could be done explicitly like this:
(defrule abc
...
=>
((engine) startTransaction)
(assert (123))
(assert (456))
((engine) endTransaction)
)
or like this:
(defrule abc
...
=>
(transaction
(assert (123))
(assert (456))
rollback
(...)
)
)
Another possibility - since the (assert) function can take more than one
fact, it could be extended to assert all the supplied facts atomically like
so:
(assert (?fact1) (?fact2) TRUE) ; optional "atomic" argument
In addition, a new jess API method could be added to take an array of Facts
like so:
Rete#assertFacts( Fact[] factArray, Context context, boolean atomic );
to match the modified behavior of (assert).
BTW - there isn't an Rete#assertFacts(Fact[] facts, Context context ) method
to mirror the existing behavior of (assert).
I know I'm referring to multiple facts being asserted but I think the
problem of "salience/agenda inversion" for a single fact can be generalized
to more than one fact.
The granularity allowed here is similar to field/record/table/database level
locking in databases. FWIW, an interesting high-concurrency approach found
in PostgreSQL is described here:
http://www.linuxgazette.com/issue68/mitchell.html
My 2cts worth.
alan
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]
--------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
