More multitasking (was: Re: Background tasks slow UI?)

Scott A Crosby crosby at qwes.math.cmu.edu
Sun Sep 16 09:10:08 UTC 2001


On Sat, 15 Sep 2001, Rob Withers wrote:

> Scott, did you say no, it can't be done? :-)  I agree with all that

I believe that squeak would not be enhanced by requiring fine-grained
locking on every object.  If nothing else, I really don't want to explain
concurrency to children. :)

> shouldn't have to deal with multiple processes (threads, tasks).  We
> don't have to in squeak because of the wonderful stepping engine,
> which drives Morphs, Scripts, Wonderland, Sockets.  We should be able

Do you know something I don't? I didn't see any way in which sockets
interfaced with the stepping engine.

> to come up with a good simple mechanism to allow for concurrency,
> without compromising either safety or responsiveness.

Concurrency is something to be avoided..  I think we're better off
searching for how to obtain safety and responsiveness.

>
> We have cooperative multitasking, where another process at the same
> priority won't interrupt the running process.  I should have stated
> that I was interested in time-slicing.
>

I think you can do this with one line:

Alter Interpreter>>resume:

I'm guessing that if you changed it to 'newPriority >= activePriority', it
would work? Thats the closest I've found to the scheduling stuff.

Another option for preempting would be to have a high priority process
which can optionally suspend another process.

> Let me simply state what capability I would like.  I want to enable
> background processing, and foreground stepping, without affecting the
> responsiveness of the UI.  Many background tasks can be long running,

This sounds reasonable and should be what squeak is doing.

> which would freeze the UI if they are at a higher or equal Priority.

Then set them to be below UI priority. If you set it to be equal to UI
priority, expect the UI to e slow.

> Even step methods can be long running, thus starving other steppers.

Then they're miswritten? Have the step method check an external mutex
created by a processing thread and if it has new data, display it then.

Another option is to put up a timeout on step methods. If one runs more
than (say) 30ms, have it bring up a debugging error.

> If we process with time-slicing and use a good event model, we could
> move many tasks into the background, and even if they are higher
> priority and long running, we could time-slice enough to remain

Now you're confusing me.. How can one have a 'high priority background
task'.  Semantically, I mean that to mean that you have two priority
ranges:


  0-10  background
 10-20  foreground

Where high priority background is 7.. Foreground always has a higher
priority than background.

Thus, all unused foreground capacity is dedicated to background
processing.

Yes, I've done this for my chat server stuff. Even when its at the
busiest, I see no degradation with the UI whatsoever.

> responsive.  The async code I posted recently handles the async events
> between processes.  My Task code does something very similar to the
> TCL event loops.
>
> Seeing IO occur without busywaits is also desirable, although contrary
> evidence has been posted.  Blocking IO is a cleaner design, and we can

Blocking IO or poll() (and/or select()) based IO are two techniques for
IO without busywaits. Right now, it does busywait.

> gain asynchronous IO by registering a callback (#when:asend:to:) which
> would be activated in the Morphic Process.  This would maintain thread
> safety, as long as different threads didn't access the same object.

Nah, a better technique would be to allow a process to block on multiple
semaphores. IF any of them gets signalled, the thread wakes up and is told
which semaphore unblocked. Then, you have IO semaphores, which the VM
signals when there is new IO.

Right now, there's no way to do this that I know of in squeak, without
busywaiting and checking each of the semaphores in turn. (And that
implementation has a race condition where the semaphore appears OK to
grab, but actually isn't when you try to grab it a moment later.)

With this primitive, one can implement your scheme of async notifications,
or I could do my scheme, where the process just deals with the sockets
directly without dispatching to anything else.

Squeak is great, but I'd love for it to have more infrastructure.

> Part of the desire for this is for scientific applications, like the
> biosqueak effort.  Imagine the we could each offer 10% of our
> processor to a distributed task server, and we could each submit tasks
> for long running computation.  I would love to offer some of my
> machine, but I want it to be safe and non-invasive to my work.  This
> says sand-baxed and time-boxed, to me.  Is there an easier way to gain
> these features?

Hey, please do this, except design it to be lightweight, so you can run a
few hundred untrusted processes safetly. You do this and I'll kiss your
feet, cause I want this, but am dreading the actually doing it part.


Scott


--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.







More information about the Squeak-dev mailing list