So what's your experience about locks during runtime of Jess, say
when there's a fair load ??
Paul
At 09:55 -0800 27/01/01, Frank Sommers wrote:
>Hello Paul,
>
>Talking about asynchronous usage, I'm working on a system now that uses
>Jess with JavaSpaces and Jini. Essentially, Jess creates workqueues in the
>space based on rules. Thus, facts coming from different sources are
>deposited (written) into the space. A separate process takes these from
>the space, and processes them using Jess. Then it writes the results back
>to the space. This facilitates a workflow application.
>
>Best,
>
>Frank
>
>
>
>On Fri, 26 Jan 2001, Paul Libbrecht wrote:
>
>>
>> Hi,
>>
>>
>> We'be been using jess with pleasure and success in our current
>>development...
>> it turns out we're thinking into going to something more elaborate
>> and questions about threading happen.
>>
>> Is jess prepared for real multi-threading ?
>> I have the feeling it is such but I am not too sure.
>>
>> In particular, we might want to make the following (kind of obvious)
>> mechanism to replace a pattern like a function call by a message
>> exchange:
>>
>> - The function call is launched, the method launching it returns
>> (making a new thread or doing something more elaborate like buffering).
>> - When the result is ready a fact is asserted using the Rete object.
>>
>> This should happen while Jess is still "running" or it might need to
>> be "restarted"...
>>
>> Is this imaginable ?
>>
>> Paul
>>
>>
>> PS: just found the following in the docs
>> >Jess can be used in a multithreaded environment. The jess.Rete class
>> >internally synchronizes itself using several synchronization locks.
>> >The most important lock is a global lock on all rule LHSs: only one
>> >assert or retract may be processing int a given jess.Rete object at
>> >a time. This restriction is likely to be relaxed in the future.
>> >
>> I fear we precisely enter in this category: transforming most of the
>> function calls in such a message-passing mechanisms will have Jess
>> spend most of its time in fact-assertion (storage distribution ?)
>> then LHS evaluation. Actually those two things are probably done at
>> the same time. If they are, then indeed we will have a fair amount of
>> deadlocks and should provide queues for the entering messages.
>> Alternatively, version 6 might solve the trouble, ....
>>
>> ---------------------------------------------------------------------
>> 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]
---------------------------------------------------------------------
