Skip to Content.
Sympa Menu

k-user - Re: [K-user] Thread to start execution with unassigned variables

k-user AT lists.cs.illinois.edu

Subject: K-user mailing list

List archive

Re: [K-user] Thread to start execution with unassigned variables


Chronological Thread 
  • From: Traian Florin Şerbănuţă <traian.serbanuta AT fmi.unibuc.ro>
  • To: Omar Duhaiby <3omarz AT gmail.com>
  • Cc: "k-user AT cs.uiuc.edu" <k-user AT cs.uiuc.edu>
  • Subject: Re: [K-user] Thread to start execution with unassigned variables
  • Date: Wed, 3 Sep 2014 07:25:03 +0300
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/k-user/>
  • List-id: <k-user.cs.uiuc.edu>

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



Archive powered by MHonArc 2.6.16.

Top of Page