Weird threading question, anyone know how to do this?

  • Thread starter Thread starter Jeff Brown
  • Start date Start date
J

Jeff Brown

I want to implement the following behavior...

1. I start a subordinate thread running. Suppose it initially runs code
section A.

2. At the end of code section A, before it gets to code section B, the
subthread is suspended (by having it call Wait() on an AutoResetEvent, for
example).

3. While the subthread is suspended, the main thread somehow captures and
preserves the subthread's current "execution state."

4. The event is signaled, and the subthread proceeds on its way. Now it's
running code section B.

5. At the end of code section B, before it gets to code section C, the
subthread is suspended again.

6. Now here's the fun part. While the subthread is suspend, the main thread
somehow reinstates the subthread's execution state, which it preserved in
step 3.

7. The event is signaled and the subthread proceeds on its way. But, now,
it's re-running code section B, as if for the first time!

8. This process could be repeated any number of times, such that the
subthread could run code section B any number of times, each time thinking
that it's the first time.

Back in the old days, I would have done this by preserving and then
reinstating the CPU's program pointer, registers and stack contents.

Is there any way to do this in the .NET world? Thanks for any help.
 
Jeff said:
Back in the old days, I would have done this by preserving and then
reinstating the CPU's program pointer, registers and stack contents.

Is there any way to do this in the .NET world? Thanks for any help.
Click to expand...

Why so low level? Just create some class to store the state data and
make the object accessible to both main and sub thread. Let the sub
thread run in a simple while (!done) loop, processing whatever there is
in the state object...?

Max
 
Thanks for the reply.

My description was probably oversimplified. In the actual application, the
subthread can become suspended at any of many points in the code. It could
occur within a top level method, or deep within a nested method call.

At whichever point the subthread becomes suspended, I need to be able to
capture and subsequently reinstate its execution state. So, for example, if
it's suspended while deep within a nested method call, I need to be able to
preserve, and subsequent reinstate, the entire call stack.
 
Why do you need to perserve and reinstate the threads call stack. Why not
just block on events and continue on when the event becomes signaled? You
did not state the reasons for this call state work.

--
William Stacey [MVP]

| Thanks for the reply.
|
| My description was probably oversimplified. In the actual application, the
| subthread can become suspended at any of many points in the code. It could
| occur within a top level method, or deep within a nested method call.
|
| At whichever point the subthread becomes suspended, I need to be able to
| capture and subsequently reinstate its execution state. So, for example,
if
| it's suspended while deep within a nested method call, I need to be able
to
| preserve, and subsequent reinstate, the entire call stack.
|
| | > Jeff Brown wrote:
| >> Back in the old days, I would have done this by preserving and then
| >> reinstating the CPU's program pointer, registers and stack contents.
| >>
| >> Is there any way to do this in the .NET world? Thanks for any help.
| >
| > Why so low level? Just create some class to store the state data and
make
| > the object accessible to both main and sub thread. Let the sub thread
run
| > in a simple while (!done) loop, processing whatever there is in the
state
| > object...?
| >
| > Max
|
|
 
My app is a kind of AI app that analyzes the outcomes of various decision
points, attempting to determine the "best" net result.

Each decision point represents a choice made by a user. During its
lookahead/analysis phase, the AI calculates all possible responses, then,
for each response, performs a "test run" of the code from that point
forward. Each "test run" can involve further decision points, with their own
branched test runs, and so on.

Of course one way to implement this is with a humongous state machine, and
that's essentially how I've implemented it so far.

But, the app would be a million times cleaner if I could implement all of
the logic as straightforward procedural code... for example, each decision
point is simply a "switch" statement, with each case calling a nested method
that contains its own "switch" statement, etc.

And hence my question. Suppose, at each decision point, we could...

1. Preserve the thread state, including its call stack (because the first
thing that the code might want to do, after the thread is restarted, is
return the selected option to its own caller).

2. Store one of the possible options into a static location.

3. Let the thread run, using that option, until it reaches a logical
conclusion. Evaluate the worth of the result.

4. Restore the thread state, effectively "rewinding" the app back to the
decision point (including its call stack).

5. Store the next option into the static location, and let the thread run.

6. Lather, rinse, and repeat, until all options have been considered.

I hope I'm explaining this well enough.
 
Jeff said:
My app is a kind of AI app that analyzes the outcomes of various
decision points, attempting to determine the "best" net result.

Each decision point represents a choice made by a user. During its
lookahead/analysis phase, the AI calculates all possible responses,
then, for each response, performs a "test run" of the code from that
point forward. Each "test run" can involve further decision points,
with their own branched test runs, and so on.

Of course one way to implement this is with a humongous state
machine, and that's essentially how I've implemented it so far.

But, the app would be a million times cleaner if I could implement
all of the logic as straightforward procedural code... for example,
each decision point is simply a "switch" statement, with each case
calling a nested method that contains its own "switch" statement, etc.

And hence my question. Suppose, at each decision point, we could...

1. Preserve the thread state, including its call stack (because the
first thing that the code might want to do, after the thread is
restarted, is return the selected option to its own caller).

2. Store one of the possible options into a static location.

3. Let the thread run, using that option, until it reaches a logical
conclusion. Evaluate the worth of the result.

4. Restore the thread state, effectively "rewinding" the app back to
the decision point (including its call stack).

5. Store the next option into the static location, and let the thread
run.
6. Lather, rinse, and repeat, until all options have been considered.
Click to expand...

Look into Fibers. I don't know how/if .NET supports or exposes Fibers, but
I think you could get pretty close to what you want using them.

Have your thread convert itself to a fiber. Now, each time you want to
evaluate a set of conditions, create a new fiber that runs until it reaches
the end, then switches back to the first fiber. The first fiber then
destroys the subordinate fiber and waits for asnother event.

-cd
 
Back
Top