Multitasking in Oberon 
Author Message
 Multitasking in Oberon

The problem seems to be that many people write off Oberon immediately
when they see that it has no multiprocessing, without noticing that under
Oberon they don't need multiprocessing for doing the things they want to be
doing.

In a conventional OS, each application has a "main loop" that accepts
user input. In order to run several of these applications concurrently,
you need several processes to keep each of these loops alive - wasting a
lot of machine ressources. In Oberon, there is no such thing as an
"application", just modules that export a series of commands. You can
still run your favorite Oberon text editor and graphics editor
concurrently, but the user interaction is carried by a single thread
that is part of the OS. Yes, structuring an application into a set of
commands need some thinking - you cannot simply translate an existing
model of an application. But the benefits are worth it.

I admit that there are applications for which multitasking would be
nice, and Oberon currently does not address these problems, but I claim
that the majority of criticism of Oberon's lack of multiprocessing have
come from people who simply haven't understood Oberon's concept of
one-process multitasking.

Michael Franz



Tue, 31 Oct 1995 17:19:18 GMT  
 Multitasking in Oberon

Quote:
(Michael Franz) writes:
>The problem seems to be that many people write off Oberon immediately
>when they see that it has no multiprocessing, without noticing that under
>Oberon they don't need multiprocessing for doing the things they want to be
>doing.

Why do you think so? But let's read on...

Quote:
>In a conventional OS, each application has a "main loop" that accepts
>user input. In order to run several of these applications concurrently,
>you need several processes to keep each of these loops alive - wasting a
>lot of machine ressources.

NO! In general (except for programs written by especially dumb programmers),
applications call a procedure provided by the OS, window system or whatever,
that blocks, waiting for an input event (like XNextEvent) instead of doing
a busy waiting loop. As soon as this procedure is called, control is passed to
the scheduler, and the time wasted in waiting is just about 0. If an input
event occurs (the user moves the mouse, strikes a key, or the hardisk
announces the SYNC ok), the scheduler reawakens the sleeping process, and
passes it a pointer to an event descriptor. From the application's point of
view, a procedure has been called that immediately returned with an an input
event ready.

Quote:
> In Oberon, there is no such thing as an
>"application", just modules that export a series of commands.

But not every "application" may fit into this mold.

Quote:
>You can
>still run your favorite Oberon text editor and graphics editor
>concurrently, but the user interaction is carried by a single thread
>that is part of the OS.

In Oberon, input handling is implemented as this: You write an event handler
which will be associated with your window. If the mouse enters your window,
or some other event occurs while the pointer is inside the window, the
Oberon System sends a "message" to the handler (i.e. it calls the handler,
passing it a pointer to the event descriptor). The handler does whatever is
needed (for example, redrawing the mouse at its new position) and exits.
(The procedure ends).

Now here is the problem: Try to do a calculation in the background.

Suppose your event handler calls the calculation procedure (call it CALC)
explicitely. The calculation sure should be FAST, otherwise you might as well
go for some coffee! Remember that the flow of control has been given to your
handler, and there is no preemption. Make sure to call the garbage collector
sometimes too, otherwise you might end up without memory; who do you think
might collect non-referenced memory cells while you grab all the processor
cycles?

If the calculation is lengthy, you might decide to do one calculation step
each time the handler is activated. This sort of works: the handler calls
CALCSTEP, processes the input events, then exits. Only--you have to make sure
that the handler is called repeatedly by clicking or moving the mouse
constantly. Get ready for some RSI...or find a possibilty to send
time events to your handler. This may work if you insert an event sending
procedure in the Oberon Main Loop. But then we could as well install CALCSTEP
into the loop, couldn't we?

So we go for the third possibility: We install a CALCSTEP into the Oberon
Main Loop. This loop checks whether any input device changed its state, and
dispatches messages to the pertaining windows by calling the appropriate
handler. This is the ONLY possibility to install a background procedure
(and, sorry, there is no "nice"-ing), and it works! Only, it's not very
transparent to the user.

Quote:
>Yes, structuring an application into a set of
>commands need some thinking - you cannot simply translate an existing
>model of an application. But the benefits are worth it.

Nah!

Quote:
>I admit that there are applications for which multitasking would be
>nice, and Oberon currently does not address these problems,...

And never will, unless you introduce the monitor concept (or some equivalent)
into the Oberon language itself, then rewrite every application. Suppose
two commands are started concurrently...Ok, let's not even THINK about it.

Quote:
>...but I claim
>that the majority of criticism of Oberon's lack of multiprocessing have
>come from people who simply haven't understood Oberon's concept of
>one-process multitasking.

I hope this helped somewhat.

Quote:
>Michael Franz

David Tonhofer (That's me, really!)

Appendix
--------

Insert a SCSI device polling procedure into the Oberon Main loop.

(This one was programmed while attending Mr. Wirth's classes)

MODULE Target;

<...Stuff deleted...>

VAR    task : Oberon.Task;

(* This procedure calls the appropriate communication procedures          *)
(* Notice that the system will not accept input until Manage has finished *)

PROCEDURE Manage;
VAR mesg : String;
    res  : BOOLEAN;
    len  : LONGINT;
    com  : CHAR;
BEGIN
   Reset;
   WriteText("--Initiator-Request--",TRUE);
   Select(res);
   IF res THEN
      Command(com,mesg,len,res);
      IF res THEN
         IF    com="R" THEN Read(mesg,len)
         ELSIF com="S" THEN Send(mesg)
         ELSIF com="D" THEN Delete(mesg)
         ELSIF com="M" THEN Message(mesg)
         ELSE  WriteText("Unknown command!",TRUE)
         END
      ELSE
         WriteText("Error in command-phase.",TRUE)
      END
   ELSE
      WriteText("Error in select-phase.",TRUE)
   END;
   Reset
END Manage;

(* This procedure will be installed into the loop *)

PROCEDURE Serve*;
BEGIN
   IF SYSTEM.BIT(CSB,1) THEN (* Something up on the SCSI port *) Manage END;
END Serve;

(* Insert task into oberon loop *)

PROCEDURE Start*;
BEGIN
   NEW(task);
   IF task=NIL THEN
      WriteText("Task not installed.",TRUE)
   ELSE
      WriteText("Task installed.",TRUE);
      task^.handle:=Serve;
      Oberon.Install(task);
      Reset
   END
END Start;

(* Remove task from oberon loop *)

PROCEDURE Stop*;
BEGIN
   Oberon.Remove(task);
   WriteText("Task removed.",TRUE)
END Stop;

END Target.



Sun, 05 Nov 1995 18:33:14 GMT  
 Multitasking in Oberon

Why beat around the bush? Oberon has no multitasking, just
like MS-DOS.

That is just a plain pain in the ass. But that's the way it seems
to be. What I don't know is whether Oberon will support multitasking
in the future. If anyone has a clue, please let us all know.

Jan



Sun, 05 Nov 1995 20:05:54 GMT  
 Multitasking in Oberon

Quote:

>Why beat around the bush? Oberon has no multitasking, just
>like MS-DOS.

>That is just a plain pain in the ass. But that's the way it seems
>to be.

At least with considerable programmer care you could implement multi-threaded
applications though in Modula2 under Dos (eg TopSpeed's Process module). Would
be nice to see a portable version of that library. From memory, the Dos
version didnt really include many OS calls (the OS/2 version was different
story but much nicer since the threads were supported in the underlying
OS).

                Phil



Mon, 06 Nov 1995 04:27:57 GMT  
 Multitasking in Oberon

Quote:

> >Why beat around the bush? Oberon has no multitasking, just
> >like MS-DOS.

From what I've read, Oberon (the Oberon _system_, not the language), has
'cooperative multitasking', like Windows. (After a command has excecuted, it
passes control back to the system.)

Still, I agree that multitasking, for all its disadvantages (deadlocks, race
conditions...) is useful and necessary, even on a small workstation or personal
computer -- waiting for something to finish executing before you get on and do
something else can be a real pain at times (a general obsertvation -- I've never
actually used Oberon).

--
|     \=====\  | Andrew Forrest               -  2nd Year Computing Science   |

|   /==\\==(   |--------------------------------------------------------------|
| _(    )\     | MS-DOS-awareness signature. Millions worldwide still suffer. |



Mon, 13 Nov 1995 20:15:56 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Oberon-2, records and multitasking.

2. Frage Oberon 3 / Question Oberon 3

3. CD-Oberon - Oberon/F

4. CD-Oberon Oberon 3 Printer Problem

5. Oberon System 3 / Native Oberon projects

6. inquiry about Visual Oberon/PC Native Oberon System 3

7. Native Oberon: Getting DOS based installation out of Oberon-0

8. Oberon-2 in Native Oberon System 3

9. modula2-to-Oberon, C++-to-Oberon

10. oberon kernel sources (Article 4814 in comp.lang.oberon)

11. POLL: Interest in PC Oberon (Native Oberon)

12. Oberon-Growth-Limit was Re: Oberon: beginners questions

 

 
Powered by phpBB® Forum Software