[M3devel] cooperative suspend?

[Tony Hosking]

Ultimately we don't really want stop-the-world at all.  What we really need is per-thread suspension.  For scalability we should be aiming to stop threads individually rather than all at once.  This means some sort of per-thread (local) mechanism.

On 27 Apr 2010, at 05:01, Jay K wrote:

> 
> cooperative suspend
> 
> 
> Tony, you mind if I take a stab at "cooperative suspend"
> fairly soon?
> I can't find a good way to suspend threads on VMS.
>   Or even get context in a signal handler.
> It will be a boolen in Target.i3, so no existing targets affected.
>   Of course I'll test it on an existing target with the boolean set wrong. :)
>   
>   
> To optimize size instead of speed, I think the "every so often
> extra generated code" should be a call to a parameter-less function.
> Instead of checking a per-thread or global variable.
> 
> Something like:
> 
> 
> VAR threadRequestingSuspend: ADDRESS;
> 
> 
> PROCEDURE Thread.PollSuspend()
>   BEGIN
>     IF threadRequestingSuspend = NIL THEN RETURN END;
>     PollSuspendSlow();
>   END PollSuspend;
> 
> 
> (* This is split to avoid needing a frame in PollSuspend. *)  
> PROCEDURE PollSuspendSlow()
>   VAR self: ADDRESS;
>   BEGIN
>     IF threadRequestingSuspend = NIL THEN RETURN END;
>     self := GetActivation();
>     IF self = threadRequestingSuspend THEN RETURN END; (* important consideration! *)
>     GetContext(self.context); (* roughly *)
>     self.suspended := TRUE; (* roughly *)
>     WaitForResume(); (* details to be determined, either the semaphore
>                       * or maybe acquire per-thread lock. *)
>   END PollSuspendSlow;
> 
> 
> The poll call could also be a function pointer and usually point to a function that does nothing.
> But that'd require loading the address from a global, and calling it.
> Probably more bloat than calling direct instead of indirect.
> 
> 
>  - Jay
>