K-user mailing list

[Omar Duhaiby <3omarz AT gmail.com>]

Thanks for your reply. The first solution is a good one if the upper cell is a global context that can also keep some mappings private to certain threads perhaps using a thread ID.

The second solution is already what I'm doing. I do have a savior thread. I should've said this before but I just found out that the savior rule is never matched! It turns out I have a bigger problem in the design of my rules. The problem mainly is that I can't give one rule higher precedence than others, which I asked about in another thread, so I will have to redesign the whole thing.

Thanks for your help.

On Wed, Sep 3, 2014 at 7:25 AM, Traian Florin Şerbănuţă <traian.serbanuta AT fmi.unibuc.ro> wrote:

Hello,

Your problem is very clear.  The issue is that your context cell is "local" to the thread.

The way you wrote the rules, each thread modifies its own context, and thus the second rule cannot change the first thread's context.

There are two solutions:  one is to make the context shared among threads by placing it to a higher level in the configuration and then updating the rules accordingly:

2014-09-03 1:09 GMT+03:00 Omar Duhaiby <3omarz AT gmail.com>:

Hello,

I've been struggling with this problem for a while. I need to create a thread with a variable X mapped to nothing, and let it start execution until it reaches the unassigned variable and get stuck there. Don't worry. It won't be stuck forever, since another thread is going to assign a value to X thus by releasing our mighty thread from its bonds to continue execution with the newly assigned value to X.

How do I do that?!

Here is what I have tried. When I create the mighty thread, I do:
some condition here

 

 (. => <thread>...
        <k> E1 </k>

    ...</thread>)

        <context> Context:Map (X |-> ?V:Val) </context>

when notBool (X in keys(Context))

 

Then the savior rule acts like:

        <thread>...
            some conditions
        ...</thread>

            <context>... X |-> (_ => V) ...</context>

I would say this is the more robust way.  Alternatively you can have one thread modify the context of another thread, but usually this would require additional constraints to make sure we are updating the right thread.  If so, the rules could look something like:

 

 (. => <thread>...
        <k> E1 </k>
        <context> Context:Map (X |-> ?V:Val) </context>
    ...</thread>)

when notBool (X in keys(Context))

 

Then the savior rule acts like:

        <thread>...
            some conditions
        ...</thread>

                   <thread>... 

            <context>... X |-> (_ => V) ...</context>

                  ...</thread

 

Note that the second rule matches another thread (the one whose context needs updating) in addition to the "savior" one.

Best wishes,

Traian