[M3devel] the need for cooperative suspend

Sat May 2 21:13:31 CEST 2015

In the preemptive case, you call SuspendThread and a hardware interrupt is sent to the processor. 

Cooperative suspend does not have this power.

There ends up being, I guess, an analog between non-polling code and the "fixed" wow64 method that is also easily starved w/o more sophistication. 

Thinking more about this...maybe preemptive is viable with a little more work. In particular we can record when we leave "managed" code and leave a reliable stack pointer for ourselves.

We can then safely preempt "native" code, getting context from our own data structures instead of the operating system. Native code though could allocate traced data though, without registering with the runtime somehow.

 - Jay

On May 2, 2015, at 8:57 AM, <mika at async.caltech.edu> wrote:

> Jay, 
> 
> Can you explain precisely what you mean by "suspend"?
> 
> A thread is suspended by ... a timer expiration?  Another thread at higher priority needing resources?
> 
> I'm thinking about a tight loop "for(;;) ;"... how do you stop a thread from running that (it could have
> been coded in assembly...)?
> 
> Jay K writes:
>> --_6bc62225-3263-437a-a88c-4b1ff9473d58_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> We really need to move away from preemptive suspend.
>> 
>> 1) It is a large fraction of the target-dependent code in m3core.
>> =20
>> 
>> 2) It doesn't really work in "wow64"=2C the x86-on-amd64 Windows system.
>> The SuspendThread + GetThreadContext does not actually reliably give you
>> current and coherent context.
>> I'm not sure about x86-on-ia64.
>> =20
>> 
>> The context can be old.
>> The context can be mid-update. Which might be ok=2C depending on what the =
>> updates are.
>> LIke if Eip and Esp are being updated=2C we don't care about Eip anyway.
>> =20
>> 
>> You can find out if either is the case=2C and let the thread run longer=2C
>> but being in a long running syscall I believe is reported as possibly
>> invalid even though it is valid.
>> =20
>> =20
>> NT/native is ok.
>> =20
>> 
>> We should just use cooperative suspend and not worry about it.
>> =20
>> =20
>> Thanks=2C
>> - Jay
>> 
>> 
>> =20
>>                         =
>> 
>> --_6bc62225-3263-437a-a88c-4b1ff9473d58_
>> Content-Type: text/html; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>> 
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 12pt=3B
>> font-family:Calibri
>> }
>> --></style></head>
>> <body class=3D'hmmessage'><div dir=3D'ltr'>We really need to move away from=
>> preemptive suspend.<BR><br>1) It is a large fraction of the target-depende=
>> nt code in m3core.<BR>&nbsp=3B<BR><br>2) It doesn't really work in "wow64"=
>> =2C the x86-on-amd64 Windows system.<BR>The SuspendThread + GetThreadContex=
>> t does not actually reliably give you<br>current and coherent context.<BR>I=
>> 'm not sure about x86-on-ia64.<BR>&nbsp=3B<BR><br>&nbsp=3BThe context can b=
>> e old.<br>&nbsp=3BThe context can be mid-update. Which might be ok=2C depen=
>> ding on what the updates are.<br>&nbsp=3BLIke if Eip and Esp are being upda=
>> ted=2C we don't care about Eip anyway.<BR>&nbsp=3B<BR><br>You can find out =
>> if either is the case=2C and let the thread run longer=2C<br>but being in a=
>> long running syscall I believe is reported as possibly<br>invalid even tho=
>> ugh it is valid.<BR>&nbsp=3B<BR>&nbsp=3B<BR>NT/native is ok.<BR>&nbsp=3B<BR=
>>> <br>We should just use cooperative suspend and not worry about it.<BR>&nbs=
>> p=3B<BR>&nbsp=3B<BR>Thanks=2C<br>&nbsp=3B- Jay<br><br><br>&nbsp=3B<BR>            =
>>            </div></body>
>> </html>=
>> 
>> --_6bc62225-3263-437a-a88c-4b1ff9473d58_--