Re: Thread programming model

On Fri, 18 Aug 2000, Steven W McDougall wrote:
> I've spent the last 3 years programming WindowsNT threads in MSVC++,
> and I *really* like it. I want similar capabilities in Perl6.
> 
> 1 The C++ thread model
> Here is the thread model that I have in C++. It is a starting
> point for thinking about what I want in Perl.
> 
> Every thread sees 
> - the same code
> - the same globals
> - the same heap
> 
> Each thread has its own stack.
> 
> Threads can obtain thread-local global storage. I've never needed to
> do this.

Really?  (No commentary, just... surprised.)

> 
> For synchronization, I have 
> - critical sections
> - mutexes
> - semaphores
> - events
> - timers
> - timeouts
> - select
> - wait for thread termination
> - wait for all
> - wait for any

Not knowing MSVC++ lingo, are any of these the same as conditionals?

> 
> 3. Modules and re-entrancy
> RFC1v2 objects to this model on the grounds that modules won't be
> reentrant if they see the same globals in different threads. I think
> this is the tail wagging the dog.

Not necessarily.  I think the majority of Perl usage will be
single-threaded in nature.  I think the majority of the modules written
will be written by people without multi-threading in mind.  It could
mean that some modules go unwritten because the person may not
understand or be comfortable writing a multi-threaded module. 

In most cases, each module is self-contained, but may use globals to
facilitate its own work.  If two different threads are using this
module, you're going to get global corruption.  Of course, you address
that below.

> 
> 3.1 Programs need globals
> The reason I like threads is that I can write some code, spin off some
> threads, and then share data between them. If every thread sees a
> different copy of the globals, then I might as well fork processes.

Every thread has its own copy of its own globals.  Every thread has
access to the program global space for sharing data.  The only
difference in our proposals is which one is the default.  I elected to
save a lot of people a lot of work, and have just a few people do a
little work.

You have to write the code to handle the threads. While you're writing
that code, share the data you want to share.  I'm not saying you
can't share it, just that you must explicitly share it.  (Even if
everyone was doing all multi-threaded work, this would still be an
advantage, although since you say that you've never needed thread-level
globals, I don't expect you to buy that.)

 > 
> 3.2 Modules shouldn't use globals
> If you want your modules to be reentrant, then you have to write them
> that way. Rule 1 is *no globals*. 

Huh?  Which global are you talking about here?  Program globals, or
thread globals?

 > The most common use of modules is to
> implement an object,

Is this true, or an assumption you are making?  (I'm not refuting it,
and am not going to look through all of CPAN to count how many created
objects, how many are procedural, and how many do both.)

>  and the object should get everything it needs from
> its instance data. This isn't just a threading issue: it is basic OO
> practice, going all the way back to perlobj.pod in 1995.

Yes, but aren't statics in Perl objects implemented as globals?
And what about the modules that aren't OO?

> 
> Existing Perl5 modules may well turn out not to be reentrant. The
> solution to that is to rewrite the modules, not contort Perl6 to
> accommodate them. 

Hmmm, better start those rewrites now, if you expect to be done in
time.  Reuse.  Double plus good.

Look, everyone needs a module to run in a single thread.  Everyone runs
code in a single thread.  Most modules don't even make sense across
multiple threads.  Since the few people multi-threading are having to
write the multi-thread code anyway, why not have them share what little
data they need to share?  They're writing the code anyway.  

 What contortions?

 > 
> 4. use foo

Yes, I recognize that this is a problem that your solution does
indeed addess, while for me it is still but a problem.

 -- 
Bryan C. Warnock
([email protected])