🚀 go-pugleaf

In <497qmr$3sf@cville-srv.wam.umd.edu>, lotu@wam.umd.edu (Arcadio Alivio Sincero) writes:
>
>I was reading a FAQ on the Modula 3 language, and it said amongst the 
>things it adds to Modula 2 is the support of lightweight processes, or 
>threads.  Now, I thought this functionality was already present in Modula 2.
>
>I don't use Modula 2 all that much (haven't for years ... never really
>needed to ... until now), but as I was learning about Modula 2 a few years
>back I seem to remember seeing in the book I was using the topic of
>concurrent processes.  I was using MS-DOS at the time, and the thought of
>concurrent processes was really exciting ... especially on a
>non-multitasking OS such as DOS. 
>
>A couple years later, I decided to "expand my horizons" and dump DOS for
>good and ventured out into the world of multitasking, multithreading,
>32-bit OS's.  My first encounter with a multithreaded OS was OS/2 ... 
>having come from a DOS background, I had no idea what a thread was.  That
>is, until I read up on it.  After reading about threads, I remembered what
>I read about Modula 2's concurrent processes, and to me they seemed to be
>basically the same thing.  Or are they? 
>
>Are M2's concurrent processes and threads the same thing or are they 
>different?
>
>
>Arcadio

Whether concurrent processes are implemented as threads or as separate processes
in a multi-tasking OS depends on the compiler implementation for that OS. The idea
behind it was to give a platform independent ability to do concurrent processing.

By definition, a thread runs in the same address space as the creator of the thread.
This meshes well with the definition of an M2 coroutine started by the SYSTEM call of
NEWPROCESS(). The only sticky point would be how TRANSFER() would be implemented. The
coroutines in many modula-2 systems seem to be scheduled internally by the program
itself instead of by the host OS. This being said, one can argue about whether
Modula-2 coroutines should be running synchronously or asynchronously.

In MS-DOS systems, compilers like TopSpeed implemented these routines in a synchronous
fashion. This would prevent running into the majority of DOS re-entrancy problems. I am
not sure about how they implemented this in OS/2 though, nor am I familiar with how 
Gardens Point implemented their co-routine structure in their 32 bit OS/2 compiler.
I have hunch though that their co-routines are now asynchronous, with their TRANSFER
routine coming down to the OS/2 system call of DosSleep() to make the thread yield it's
CPU time slice. The other possibility is that their RTL adds another thread or something
like this to allow threads to run in a synchronous fashion. Anyone have the
source to the GPM system module?

Cheers,

Jan Walter

//   Centurion Services & Wholesale     //
//   "Quality from the Start"           //
//   Fax: (604) 279-1800                //
  *** PLEASE NOTE NEW EMAIL ADDRESS ***
//   centurion@infomatch.com            //