Well, the usual Java way of doing this is to use wait() and
notify(). To implement this with Jess, you might do the following:
1) Since there's no "synchronized" function in Jess, you could write
one (untested, but you get the idea)
public class Synchronized implements Userfunction {
public String getName() { return "synchronized"; }
public Value call(ValueVector vv, Context c) throws JessException {
Object lock = vv.get(1).externalAddressValue(c);
synchronized(lock) {
return vv.get(2).resolveValue(c);
}
}
}
2) Have a rule that calls wait() on a well-known lock object when it
sees a "pause" fact. Here I'll use fetch to get it, but it could be
from a Java method, a static member, etc.
(defrule pause
?p <- (pause)
=>
(synchronized (fetch LOCK) ((fetch LOCK) wait))
(retract ?p))
3) When thread 2 wants thread 1 to pause, it uses
rete.store("LOCK", wellKnownObject);
rete.assertString("(pause)");
4) To wake it up, #2 just says
synchronized (wellKnownObject) {
wellKnownObject.notify();
}
This doesn't seem to complicated to me -- what do you think?
I think Alan Moore wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Does anyone have a good technique for pausing rule firing?
>
> I tried to search the archives but the search function is broken at the
> moment...
>
> Here is my setup and requirements:
>
> 1) thread #1 calls runUntilHalt() in order to keep the engine running. The
> intent is to call halt() only when the system is being shut down.
>
> 2) thread #2 needs to pause and then later resume rule firing.
>
> My initial plan was to have thread #2 assert a fact, e.g. (Pause), that the
> rules will check for with a (not (Pause)) pattern to make sure they don't
> fire when this fact is present. Later, thread #2 will assert a fact, e.g.
> (Resume), that will trigger a rule to retract the (Pause) fact. I don't like
> this approach since it clutters the rules with what is otherwise an external
> "pause" aspect.
>
> As part of doing this, thread #2 needs to ensure that the rules have stopped
> firing. The only way I could think of doing this is to call run() from
> thread #2. However, I am not sure this will guarantee no more rules are
> (still?) running on thread #1.
>
> Another approach would be to have thread #2 call halt() and then in thread
> #1, check a barrier/latch set/unset by thread #2 indicating that thread #1
> should wait until thread #2 signals it to go back and call runUntilHalt(). I
> don't like this approach because thread #1 and thread #2 are from different
> parts of my system and I don't want to couple them any more tightly than
> they already are.
>
> Yet another idea is to switch the engine's focus to a module that does
> nothing but I'm not sure how to make this work since I have never used
> modules.
>
> All of this sounds very convoluted and was wondering if anyone on the list
> had any ideas about how to do this a better way.
>
> *Enhancement request* - would it be possible for the Rete class to implement
> pause()/resume() methods *or* for the (halt) command and/or the halt()
> method to take an (optional) parameter that would be returned to the
> thread(s) that have called runUntilHalt()?
>
> I know there is a public method on Rete called getActivationSemaphore() but
> I am not exactly sure how I should use this without breaking the agenda or
> causing some kind of deadlock. Any advise in this regard is appreciated.
>
> Thanks in advance.
>
> alan
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
