🚀 go-pugleaf

In article <DGqB16.Gn4@undergrad.math.uwaterloo.ca>,
Eric Giguere <giguere@csg.uwaterloo.ca> wrote:
|  You're confusing threads vs. processes.  You start a new process each
|  time you run an executable.  Each process has 1 or more threads running
|  in it, and it's the threads within the same process that you have
|  to worry about, since each thread has access to all the memory space
|  used and allocated by any other thread inside the same process.
|  
|  Depending on your linker options (or .DEF file for non-Watcom users)
|  you can set up your DLL so that its data is shared between threads
|  in different processes or only between threads in the same process.
|  Usually you want the latter, and that's the case you have.
|  
|  Here's what you should do to explore this further:  read up about
|  the StartThread method in VX-REXX and then add a second thread to
|  your program.  Make both threads call into your DLL and see what 
|  happens.
|  
|  After that experiment you'll want to learn about critical sections
|  and semaphores.

Ah, ok. I do know about semaphores and critical sections, and if I
ever add multi-threading to this particular program, I'll problably
add semaphores to the data accesses, but at the moment, my program is
just a front-end for a commandline compiler, and really doesn't need
multiple threads. For this reason, when you mentioned threads, I
automatically thought you meant process threads, not giving a single
thought to multi-threaded apps. Thanks for the clarification.

I may add semaphores to my DLL in any case, just so that if I ever do
use threads, it'll be ready.
-- 
          Carsten Whimster     bcrwhims@uwaterloo.ca
           EDM/2 Associate Editor and Book reviewer
            Team OS/2           POV-Panel/2 author
       http://www.undergrad.math.uwaterloo.ca/~bcrwhims/

Or, not use static variables, so as to avoid thread collisions (eliminate need for serializing access to shared variable).

In article <468n2k$jg@fiesta.srl.ford.com>,
Dave Boll <dboll@elvis.srl.ford.com> wrote:
|  Or, not use static variables, so as to avoid thread collisions (eliminate need for serializing access to shared variable).


well, I have this data that I am trying to move out of VX-REXX, so how
else can I do it? Even if I allocate some memory, I'll still have to
serialize access, right?
-- 
          Carsten Whimster     bcrwhims@uwaterloo.ca
           EDM/2 Associate Editor and Book reviewer
            Team OS/2           POV-Panel/2 author
       http://www.undergrad.math.uwaterloo.ca/~bcrwhims/

 > well, I have this data that I am trying to move out of VX-REXX, so how
 > else can I do it? Even if I allocate some memory, I'll still have to
 > serialize access, right?
 
It depends how you allocate the memory. If you use malloc, it is private
to each thread. The C library takes care of that. If you use DosAllocMem,
it all depends on whether the pointer is available to more than one
thread. If in fact several threads could access the memory, then you do
need some sort of serialization.
 
Charles
http://www.quercus-sys.com

In message <46jpt7$r2j@jobe.shell.portal.com> - cgdaney@shell.portal.com (Charl
es G Daney) writes:
|  
|  
|  
|   > well, I have this data that I am trying to move out of VX-REXX, so how
|   > else can I do it? Even if I allocate some memory, I'll still have to
|   > serialize access, right?
|   
|  It depends how you allocate the memory. If you use malloc, it is private
|  to each thread. The C library takes care of that. If you use DosAllocMem,
|  it all depends on whether the pointer is available to more than one
|  thread. If in fact several threads could access the memory, then you do
|  need some sort of serialization.
|   
|  Charles
|  http://www.quercus-sys.com

Is there anu advantage to doing things this way, rather than with the 
options in the lnk/def file? It seems to me that this must have been 
exactly why they enabled that in the first place. Each VX-REXX app
instance will only ever need the data in one thread (I hope), and in 
any case, they MUST have access to the same, synchronized data, which
is much more important than separating stuff out (right?).

          Carsten Whimster     bcrwhims@uwaterloo.ca
           EDM/2 Associate Editor and Book reviewer
            Team OS/2           POV-Panel/2 author
                 OS/2 and Internet consultant
      http://www.undergrad.math.uwaterloo.ca/~bcrwhims/