|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Weird threading question, anyone know how to do this?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 Brown wrote:
> Back in the old days, I would have done this by preserving and then Why so low level? Just create some class to store the state data and > 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. 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. Show quote "Markus Stoeger" <spamhole@gmx.at> wrote in message news:uabHuJoWGHA.1348@TK2MSFTNGP05.phx.gbl... > 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 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. -- Show quoteWilliam Stacey [MVP] "Jeff Brown" <worldsofinsan***@hotmail.com> wrote in message news:%23wy4F0pWGHA.1204@TK2MSFTNGP04.phx.gbl... | 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. | | "Markus Stoeger" <spamhole@gmx.at> wrote in message | news:uabHuJoWGHA.1348@TK2MSFTNGP05.phx.gbl... | > 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. Show quote "William Stacey [MVP]" <william.sta***@gmail.com> wrote in message news:%23JDHF$pWGHA.3492@TK2MSFTNGP05.phx.gbl... > 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] > > "Jeff Brown" <worldsofinsan***@hotmail.com> wrote in message > news:%23wy4F0pWGHA.1204@TK2MSFTNGP04.phx.gbl... > | 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. > | > | "Markus Stoeger" <spamhole@gmx.at> wrote in message > | news:uabHuJoWGHA.1348@TK2MSFTNGP05.phx.gbl... > | > 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 > | > | > > Jeff Brown wrote:
Show quote > My app is a kind of AI app that analyzes the outcomes of various Look into Fibers. I don't know how/if .NET supports or exposes Fibers, but > 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 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  |
|||||||||||||||||||||||
Other interesting topics