Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #100613 > unrolled thread

(Execution) Termination bit, Alternation bit.

Back to article view | Back to comp.lang.python

Contents

  (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-19 18:56 +0100
    Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-19 21:27 -0500
    Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-20 14:44 +1100
    Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-20 12:25 +0100
      Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-20 11:21 -0500
      Re: (Execution) Termination bit, Alternation bit. eryk sun <eryksun@gmail.com> - 2015-12-20 22:04 -0600
      Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-21 13:40 +0100
        Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-21 12:57 -0500
          Re: (Execution) Termination bit, Alternation bit. Grant Edwards <invalid@invalid.invalid> - 2015-12-21 19:32 +0000
            Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:25 +0100
              Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2015-12-30 00:22 +1100
                Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 22:43 +0100
                  Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-30 11:00 +1100
                    Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2016-01-03 02:18 +0100
                      Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2016-01-03 19:44 +1100
                        Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2016-01-08 12:59 +0100
            Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:42 +0100
        Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-22 16:46 +0100
          Re: (Execution) Termination bit, Alternation bit. Chris Angelico <rosuav@gmail.com> - 2015-12-23 02:56 +1100
            Re: (Execution) Termination bit, Alternation bit. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-12-29 12:23 +0100
    Re: (Execution) Termination bit, Alternation bit. Rustom Mody <rustompmody@gmail.com> - 2015-12-29 20:07 -0800
      Re: (Execution) Termination bit, Alternation bit. Steven D'Aprano <steve@pearwood.info> - 2015-12-30 23:56 +1100
        Re: (Execution) Termination bit, Alternation bit. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-12-30 12:19 -0500

Page 1 of 2  [1] 2  Next page →

#100613 — (Execution) Termination bit, Alternation bit.

Hello,

I'd like to see instruction execution enhanced with the following two ideas:

1. A termination bit, and a terminator pointer.
2. A alternation bit, and a alternate pointer.

The purpose of these bits is as follows:

Before a processor/core executes an instruction both bits are examined.

1. If the termination bit is set the instruction is not executed and instead 
the processor sets the instruction pointer to the termination pointer.
2. If the alternation bit is set the instruction is not executed and instead 
the processor sets the instruction pointer to the alternation pointer.

The idea behind this is support multi threading/parallelism better.

The idea is that Thread A could terminate Thread B immediately so that 
Thread B does not continue execution.
The idea is also that Thread A could influence Thread B to start executing a 
different path.

Hopefully these bits are enough for operating systems to add support for 
this. Some issues remaining could be items pushed on the stack.
Perhaps operating system can deal with that, or perhaps compiler or perhaps 
some other special instructions or software methods can be added.
Hopefully operating systems can include data structures per thread that can 
be loaded into the core, and into these bits and pointers so that it becomes 
active.
During a context switch these bits and pointers should be loaded 
accordingly.
So these two bits and these two pointers become part of the context.

I think these two features would be usefull to make multi-threading more 
responsive and faster reaction time to changes/events occuring.

(Eventually it would be nice if these low level features would end up in 
high level languages like Python ;))

Bye,
  Skybuck.

[toc] | [next] | [standalone]

#100619

On Sat, 19 Dec 2015 18:56:17 +0100, "Skybuck Flying"
<skybuck2000@hotmail.com> declaimed the following:

>Hello,
>
>I'd like to see instruction execution enhanced with the following two ideas:
>
>1. A termination bit, and a terminator pointer.
>2. A alternation bit, and a alternate pointer.
>
>The purpose of these bits is as follows:
>
>Before a processor/core executes an instruction both bits are examined.
>
>1. If the termination bit is set the instruction is not executed and instead 
>the processor sets the instruction pointer to the termination pointer.
>2. If the alternation bit is set the instruction is not executed and instead 
>the processor sets the instruction pointer to the alternation pointer.
>
>The idea behind this is support multi threading/parallelism better.
>
	Don't see it here... You've just enabled leaving lots of corrupted data
structures in the system... (Imagine your "termination" branch is taken
after a call that allocated a 500MB block of memory, but before the call
that returns that memory to the system).

	This is why all well-designed multi-thread (and even multi-process --
though processes are typically an OS level entity which can be killed and
all resources reclaimed as they are not in a shared memory space) tend to
rely upon known points of communication and signalling.

	One of the bedrocks of software engineering has been the concepts of
cohesion and coupling. High cohesion: a block (function, etc.) of code is
focused upon a task, not containing bits of stuff involving multiple
unrelated work. Low coupling: blocks are independent of other blocks, with
only a few known points of information transfer -- few, if any,
side-effects, no mysterious globals... They should be black-boxes whose
inner content can be changed without affecting any other code.

	Your externally inflicted bits and jumps violate all of these as they
require outside code to know what the inside looks like to make safe use of
them.

	The "bits" are not the problem, but the uncontrolled/asynchronous
transfer of control is a big problem! The "bits" themselves are nothing
more than a recreation of VMS Event Flags (or even AmigaOS signal bits) --
they can be asynchronously set; but to act upon them requires a synchronous
operation*... That is, some sort of read operation in a loop or at other
known code points at which the code itself can cleanly change its path of
execution.


* I'm ignoring ASTs -- software interrupts -- since they don't cause a
transfer of control of the thread itself; they activate, run quickly, and
return to the point of activation.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#100620

On Sun, Dec 20, 2015 at 1:27 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Sat, 19 Dec 2015 18:56:17 +0100, "Skybuck Flying"
> <skybuck2000@hotmail.com> declaimed the following:
>
>>Hello,
>>
>>I'd like to see instruction execution enhanced with the following two ideas:
>>
>>1. A termination bit, and a terminator pointer.
>>2. A alternation bit, and a alternate pointer.
>>
>         Don't see it here... You've just enabled leaving lots of corrupted data
> structures in the system... (Imagine your "termination" branch is taken
> after a call that allocated a 500MB block of memory, but before the call
> that returns that memory to the system).

Honestly, I wouldn't bother responding to this kind of thing here on
python-list. There's nothing about Python in the entire post. It's a
CPU-level feature that "might" be able to be adopted eventually by the
implementation of languages like Python. If I were to hazard a guess,
I would say that a feature like this would migrate first through CPU
discussions, then through C compilers, then to PyPy, and finally might
end up in CPython, if it got widespread use. But until it gets at
least to the PyPy level, it's not of much interest here. (Even then,
it'll be an obscure feature on a very specific platform, and probably
of only cursory interest.)

If this really IS worth doing, there'll be OS programmers all over it
for years before it ever affects Python.

ChrisA

[toc] | [prev] | [next] | [standalone]

#100627

"Richard Damon"  wrote in message news:QHody.3724$Bz5.3354@fx04.iad...

On 12/19/15 9:03 PM, Skybuck Flying wrote:

> It could be usefull if the instruction pointer/return address that was
> pushed onto the stack when the interrupt handler was called can be
> modified by the interrupt handler so that when it returns the modified
> instruction pointer is popped from the stack.
>
> This would assume:
>
> 1. To be interrupted processor pushed it's own instruction pointer onto
> the stack.
> 2. To be interrupted processor pops it's own instruction pointer from
> stack.
>
> Bye,
>   Skybuck.

"
It would be an unusual machine where you couldn't modify the return
address on the stack to change the address you return to.
"

This does make me wonder how Windows 7 terminates threads/processes/hanging 
applications.

Apperently there is some kind of mechanism for this.

Perhaps it's not fully exposed to application developers or perhaps in a 
somewhat more complex way via all kinds of APIs ?

An example of how to terminate threads/processes instantly on Windows 7 
could be interesting.

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#100630

On Sun, 20 Dec 2015 12:25:30 +0100, "Skybuck Flying"
<skybuck2000@hotmail.com> declaimed the following:

>
>This does make me wonder how Windows 7 terminates threads/processes/hanging 
>applications.
>
>Apperently there is some kind of mechanism for this.
>
	And if you've done it you'll have seen warnings about possible data
corruption or further misbehavior of the system.

>Perhaps it's not fully exposed to application developers or perhaps in a 
>somewhat more complex way via all kinds of APIs ?
>

	Of course it is exposed... It's even called TerminateProcess

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx

>An example of how to terminate threads/processes instantly on Windows 7 
>could be interesting.

	There is also TerminateThread

https://msdn.microsoft.com/en-us/library/windows/desktop/ms686717%28v=vs.85%29.aspx

but note all the caveats about its use. Along with those of
TerminateProcess. In both cases the preferred method is for the
process/thread ITSELF to call Exit(Process|Thread) in response to some
other signal that it reads.


	Killing a process is usually "safe" -- the OS process information table
gives it access to the open file descriptors, memory allocation, etc. so
the OS can force close/release of resources.

	Killing threads is NOT "safe" -- since they share memory/resources with
the other threads in the process.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#100645

On Sun, Dec 20, 2015 at 10:21 AM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Sun, 20 Dec 2015 12:25:30 +0100, "Skybuck Flying"
> <skybuck2000@hotmail.com> declaimed the following:
>>
>>This does make me wonder how Windows 7 terminates threads/processes/hanging
>>applications.
>>
>>Apperently there is some kind of mechanism for this.
>>
>         And if you've done it you'll have seen warnings about possible data
> corruption or further misbehavior of the system.

The Windows mechanism for queueing a routine to run on another thread
is an NT asynchronous procedure call (APC). Here's an old article
about NT APCs (Almeida, 2002):

    http://www.drdobbs.com/184416590

APCs are typically used by kernel-mode code in the I/O system and
drivers. A user-mode APC can also be queued to a thread using
QueueUserAPC, but it only executes "with permission" when the thread
either calls ntdll!NtTestAlert or enters an alertable wait.

TerminateThread calls the system function NtTerminateThread, which
queues an APC to the thread to call the process manager private
function nt!PspExitThread. The thread rundown procedure is briefly as
follows:

    * Notify driver callbacks registered via
      PsSetCreateThreadNotifyRoutine.
    * If it's the last thread in the process, wait
      for all other threads to finish exiting.
    * Message any debug or termination port.
    * Run down the Win32 extended thread.
    * Cancel outstanding I/O operations, timers, and
      registry notifications.
    * Run down the kernel thread.
    * Delete the thread environment block (TEB).
    * Run down the LPC message stack.
    * Set the thread ExitStatus and ExitTime.
    * If it's the last thread in the process, close
      out the process handle table and section object.
    * Run down pending APCs.
    * Queue the thread to be reaped.

ExitThread (i.e. ntdll!RtlExitUserThread) calls the loader function
ntdll!LdrShutdownThread. This gives all interested DLL entrypoints and
TLS initializers an opportunity to do required bookkeeping and
resource management for the detaching thread. Then RtlExitUserThread
calls NtTerminateThread to let the executive handle the rest.

CPython calls the C runtime's _endthreadex, which is recommended in
place of calling ExitThread directly, especially if the CRT is linked
statically instead of as a DLL.

> In both cases the preferred method is for the process/thread ITSELF to call
> Exit(Process|Thread) in response to some other signal that it reads.

Yes, in C/C++ code. In Python code just return or raise SystemExit to
let the interpreter do this for you. Calling either ExitThread or
_endthreadex directly is a bad idea. Python's DllMain doesn't handle a
DLL_THREAD_DETACH when _endthreadex or ExitThread is called. Thus if
you pull the rug out from under the thread, the thread's tstate lock
is never released and the interpreter will hang at exit if it isn't a
daemon thread.

[toc] | [prev] | [next] | [standalone]

#100665

The original idea I posted is less about sending a signal to another 
processor.

It is more about how to break out of an instruction sequence.

Example of problem:

Main:
while Condition1 do
begin
    while Condition2 do
    begin
        while Condition3 do
        begin
            Routine1
        end
    end;
end;

Routine1:

while Condition4 do
begin
    while Condition5 do
    begin
        Routine2:
    end;
end;

Routine2:

while Condition6 do
begin
    while Condition7 do
    begin

    end;
end;

Breaking out of these kinds of loops, routines, code currently requires 
something like:

Current cumbersome solution for problem:

Main:
while Condition1 and not Terminated do
begin
    while Condition2 and not Terminated do
    begin
        while Condition3 and not Terminated do
        begin
            Routine1
        end
    end;
end;

Routine1:

while Condition4 and not Terminated do
begin
    while Condition5 and not Terminated do
    begin
        Routine2:
    end;
end;

Routine2:

while Condition6 and not Terminated do
begin
    while Condition7 and not Terminated do
    begin

    end;
end;

It can take a long while before all this code exits, plus the Terminated 
boolean is probably placed on wrong side.

It should be on the left side in case the Conditions are actual functions 
otherwise those would unnecessarily be executed as well.

Having something that can immediatly exit all of this code would be a nice 
feature to have.

Perhaps something like an exception block, perhaps it could be called a 
termination block.

Routine1:
Result = False

Execute
    while True do
    begin

    end;
    Result = True
Termination
    OnTerminate:
    begin

    end;
end;

return Result

Preferrably , optionally this can be omitted/left out.

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#100688

On Mon, 21 Dec 2015 13:40:21 +0100, "Skybuck Flying"
<skybuck2000@hotmail.com> declaimed the following:

>The original idea I posted is less about sending a signal to another 
>processor.
>
>It is more about how to break out of an instruction sequence.
>
>Example of problem:
>
>Main:
>while Condition1 do
>begin
>    while Condition2 do
>    begin
>        while Condition3 do
>        begin
>            Routine1
>        end
>    end;
>end;
>
	I do hope this is the result of over simplification for the example, as
otherwise I'd turn it into

while C1 and  C2 and C3:
	R1


>Routine1:
>
>while Condition4 do
>begin
>    while Condition5 do
>    begin
>        Routine2:
>    end;
>end;
>
>Routine2:
>
>while Condition6 do
>begin
>    while Condition7 do
>    begin
>
>    end;
>end;
>
>Breaking out of these kinds of loops, routines, code currently requires 
>something like:
>
>Current cumbersome solution for problem:
>
>Main:
>while Condition1 and not Terminated do
>begin
>    while Condition2 and not Terminated do
>    begin
>        while Condition3 and not Terminated do
>        begin
>            Routine1
>        end
>    end;
>end;
>
>Routine1:
>
>while Condition4 and not Terminated do
>begin
>    while Condition5 and not Terminated do
>    begin
>        Routine2:
>    end;
>end;
>
>Routine2:
>
>while Condition6 and not Terminated do
>begin
>    while Condition7 and not Terminated do
>    begin
>
>    end;
>end;
>
>It can take a long while before all this code exits, plus the Terminated 
>boolean is probably placed on wrong side.
>
>It should be on the left side in case the Conditions are actual functions 
>otherwise those would unnecessarily be executed as well.
>
>Having something that can immediatly exit all of this code would be a nice 
>feature to have.
>
>Perhaps something like an exception block, perhaps it could be called a 
>termination block.
>
>Routine1:
>Result = False
>
>Execute

	What happens if your externally imposed terminate signal becomes set
between the "result =" and the block identifier "execute"? Heck -- what
happens if the "result =" really becomes, say, 5 instructions at the
machine level, and your flag gets set between any two of them?

	At what granularity do you propose the checking for termination flag be
performed? (C)Python is already considered slow by some people -- are you
going to add multiple cycles to every pseudo-code instruction to have it
look up a thread data structure, check some flag in that structure, and if
set then look for some sort of termination handler within the thread's call
stack (I suppose a regular raised exception could be triggered for this).
Do you perform the check only at those intervals where the run-time is
doing thread swapping? Or maybe you only do it when the compiler determines
one has completed a statement.

	Or do you leave it all to the programmer to decide when/where
termination conditions can be safely handled?

	Me? I favor the last -- which is how practically every system I've
programmed on treats it. Externally forced termination is always a drastic
matter, and typically takes place at the entire process level.

	Modern programming languages are designed for deterministic behavior --
such asynchronous triggers are handled at defined points (by the receiving
code explicitly testing for some signal to be set). Interrupts do not
change the control flow within a thread -- they suspend the thread, do the
interrupt processing, then resume the thread where it was suspended. If the
thread needs to know the interrupt happened, the interrupt sets a flag
which the thread reads /at known points/.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#100694

On 2015-12-21, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Mon, 21 Dec 2015 13:40:21 +0100, "Skybuck Flying"
><skybuck2000@hotmail.com> declaimed the following:
>
>>The original idea I posted is less about sending a signal to another 
>>processor.
>>
>>It is more about how to break out of an instruction sequence.
>>
>>Example of problem:
>>
>>Main:
>>while Condition1 do
>>begin
>>    while Condition2 do
>>    begin
>>        while Condition3 do
>>        begin
>>            Routine1
>>        end
>>    end;
>>end;
>>
> 	I do hope this is the result of over simplification for the example, as
> otherwise I'd turn it into
>
> while C1 and  C2 and C3:
> 	R1

That's not equivalent to what Skybuck posted.  Think about what
happens when Routine1 causes Condition1 and Condition2 to become false
but Condition3 remains true.

Not that this means that all rest of what Skyhawk posted makes any
sense at all.  I've spent a lot of time programming on "bare metal",
in assembly, Pascal, PL/M, and C (including using coroutines and
various other "multi-thread" constructs with no OS support), and I
really don't see the utility of his initial suggestion.

-- 
Grant Edwards               grant.b.edwards        Yow! What a COINCIDENCE!
                                  at               I'm an authorized "SNOOTS
                              gmail.com            OF THE STARS" dealer!!

[toc] | [prev] | [next] | [standalone]

#100950

"Grant Edwards"  wrote in message news:n59k40$e27$1@reader1.panix.com...

On 2015-12-21, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Mon, 21 Dec 2015 13:40:21 +0100, "Skybuck Flying"
><skybuck2000@hotmail.com> declaimed the following:
>
>>The original idea I posted is less about sending a signal to another
>>processor.
>>
>>It is more about how to break out of an instruction sequence.
>>
>>Example of problem:
>>
>>Main:
>>while Condition1 do
>>begin
>>    while Condition2 do
>>    begin
>>        while Condition3 do
>>        begin
>>            Routine1
>>        end
>>    end;
>>end;
>>
> I do hope this is the result of over simplification for the example, as
> otherwise I'd turn it into
>
> while C1 and  C2 and C3:
> R1


"
Not that this means that all rest of what Skyhawk posted makes any
sense at all.  I've spent a lot of time programming on "bare metal",
in assembly, Pascal, PL/M, and C (including using coroutines and
various other "multi-thread" constructs with no OS support), and I
really don't see the utility of his initial suggestion.
"

Great that means you will understand the example below:

mov eax, 0
add eax, 10
mul eax, 4

There is an instruction sequence for you.

This instruction sequence is too long believe it or not.

The mission is to make the CPU break out of instruction 2 and execute 
something else.

How would you do it ?

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#100953

On Tue, 29 Dec 2015 10:25 pm, Skybuck Flying wrote:

> Great that means you will understand the example below:
> 
> mov eax, 0
> add eax, 10
> mul eax, 4
> 
> There is an instruction sequence for you.


Skybuck, this is completely off-topic for a Python forum like this.




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#100972

"Steven D'Aprano"  wrote in message 
news:5682892c$0$1587$c3e8da3$5496439d@news.astraweb.com...

On Tue, 29 Dec 2015 10:25 pm, Skybuck Flying wrote:

> Great that means you will understand the example below:
>
> mov eax, 0
> add eax, 10
> mul eax, 4
>
> There is an instruction sequence for you.


"
Skybuck, this is completely off-topic for a Python forum like this.
"

Not at all, these assembler statements can be replaced with python 
statements and then you have the exact same problem ! ;)

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#100977

On Wed, Dec 30, 2015 at 8:43 AM, Skybuck Flying <skybuck2000@hotmail.com> wrote:
> Not at all, these assembler statements can be replaced with python
> statements and then you have the exact same problem ! ;)

Then do so. Give us an example where this problem occurs in pure Python.

ChrisA

[toc] | [prev] | [next] | [standalone]

#101182

"Chris Angelico"  wrote in message 
news:mailman.64.1451433611.11925.python-list@python.org...

On Wed, Dec 30, 2015 at 8:43 AM, Skybuck Flying <skybuck2000@hotmail.com> 
wrote:
> Not at all, these assembler statements can be replaced with python
> statements and then you have the exact same problem ! ;)

"
Then do so. Give us an example where this problem occurs in pure Python.
"

I basically already did...

The while loops and calls themselfes already enough of a burdon...

Should be easy to turn that somewhat pseudo code into python code ! :)

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#101193

On Sun, 3 Jan 2016 12:18 pm, Skybuck Flying wrote:

> Should be easy to turn that somewhat pseudo code into python code ! :)

If it is so easy, why won't you do it?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#101366

> Should be easy to turn that somewhat pseudo code into python code ! :)

If it is so easy, why won't you do it?

Not sure why, I use SikuliX and it's kinda buggy and slow, and I also had 
little time, it's also pretty trivial and I doubt you guys will have a 
solution that will actually work, so it's time wasted most likely.

However I will not let the missing of code be an excuse for you guys and 
gals :) So here is the code.

It may also clearify some things cause some were already confused by the 
simple conditions it seems ! ;) :)

# Begin of Code

Condition1 = True
Condition2 = True
Condition3 = True
Condition4 = True
Condition5 = True
Condition6 = True
Condition7 = True

def Routine2():
print "Entering Routine2()"
global Condition6
global Condition7

while Condition6:
     while Condition7:
   print "routine 2: executing"

print "Leaving Routine2()"

def Routine1():
print "Entering Routine1()"
global Condition4
global Condition5

while Condition4:
  while Condition5:
   Routine2()
print "Leaving Routine1()"

# main
print "Entering main loop"

while Condition1:
while Condition2:
  while Condition3:
   Routine1()

print "Leaving main loop"

# End of Code

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#100951

"Grant Edwards"  wrote in message news:n59k40$e27$1@reader1.panix.com...

On 2015-12-21, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Mon, 21 Dec 2015 13:40:21 +0100, "Skybuck Flying"
><skybuck2000@hotmail.com> declaimed the following:
>
>>The original idea I posted is less about sending a signal to another
>>processor.
>>
>>It is more about how to break out of an instruction sequence.
>>
>>Example of problem:
>>
>>Main:
>>while Condition1 do
>>begin
>>    while Condition2 do
>>    begin
>>        while Condition3 do
>>        begin
>>            Routine1
>>        end
>>    end;
>>end;
>>
> I do hope this is the result of over simplification for the example, as
> otherwise I'd turn it into
>
> while C1 and  C2 and C3:
> R1

"
That's not equivalent to what Skybuck posted.  Think about what
happens when Routine1 causes Condition1 and Condition2 to become false
but Condition3 remains true.
"

Thanks for pointing that out to him, it's funny to see that at least that 
part of the logic you understand ! ;)

"
Not that this means that all rest of what Skyhawk posted makes any
sense at all.
"

Perhaps it will help you if I tell you the following:

1. This is just pseudo code.
2. The conditions C1, C2, C3 can be functions/routines returning booleans.

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#100734

"Richard Damon"  wrote in message news:QXSdy.6634$QG6.5135@fx31.iad...

On 12/21/15 7:40 AM, Skybuck Flying wrote:
> The original idea I posted is less about sending a signal to another
> processor.
>
> It is more about how to break out of an instruction sequence.
>
> Example of problem:
[snip]
> Bye,
>   Skybuck.

"
The issue is that if your threads are doing real work, the cleanup
needed at each point keep the environment clean for other threads likely
varies. Just arbitrarily stopping or blindly going off to something else
is very apt to create problems.

Some languages can be better at automatically cleaning up for you, these
will tend to be languages that support some form of exception
processing, as that tends to need similar support. You abort can be
treated as a type of exception that is automatically thrown when signaled.

The problem here is that most programs, while they can handle exceptions
in many spots, have some spots where exceptions will cause problems,
especially in code that is directly managing the resources. Thus, you
still need to have some definition of where to check for the breaks.
"

I can imagine that arbitrarily terminating somewhere can lead to problems 
for example in memory clean up code, where then memory leaks might occur.

Though applications do sometimes seem to clean up anyway.

One idea which immediatly comes to mind to fix this problem is to offer a 
"PushTerminationFlag" onto stack and then a "ClearTerminationFlag" 
instruction.

Then a code section can be executed without breaking or terminating.

Once that's done the code would then call "PopTerminationFlag".

At least this offers some protection against arbitrarely breaking code 
sections.

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

#100735

On Wed, Dec 23, 2015 at 2:46 AM, Skybuck Flying <skybuck2000@hotmail.com> wrote:
> One idea which immediatly comes to mind to fix this problem is to offer a
> "PushTerminationFlag" onto stack and then a "ClearTerminationFlag"
> instruction.
>
> Then a code section can be executed without breaking or terminating.
>
> Once that's done the code would then call "PopTerminationFlag".
>
> At least this offers some protection against arbitrarely breaking code
> sections.

Congratulations! You've just rediscovered 'critical sections'. So...
what happens if there's a programming bug that means you fail to pop
the termination flag? Wouldn't it be so nice if you could use...
exception handling?

Here on python-list/comp.lang.python, we have all those high level
facilities. We don't need new CPU-level features to make this work.
Are you massively cross-posting? Either way, this is pretty off-topic
for here. Read up a bit on what's already been done (most of what
you're talking about was already solved back in the 1990s when I was
programming on OS/2, and I'm pretty sure the solutions were all lifted
directly from mainframe research in previous decades), or just use
high level languages and save yourself a boatload of trouble.

ChrisA

[toc] | [prev] | [next] | [standalone]

#100949

"Chris Angelico"  wrote in message 
news:mailman.62.1450799815.2237.python-list@python.org...

On Wed, Dec 23, 2015 at 2:46 AM, Skybuck Flying <skybuck2000@hotmail.com> 
wrote:
> One idea which immediatly comes to mind to fix this problem is to offer a
> "PushTerminationFlag" onto stack and then a "ClearTerminationFlag"
> instruction.
>
> Then a code section can be executed without breaking or terminating.
>
> Once that's done the code would then call "PopTerminationFlag".
>
> At least this offers some protection against arbitrarely breaking code
> sections.

"
Here on python-list/comp.lang.python, we have all those high level
facilities.
"

Ok, if that were true, please solve the problem then with python code ! ;)

Bye,
  Skybuck.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web