At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote:
>Are Perl6 threads preemptive or cooperative?
>
>Last week, I asked whether Perl6 threads support SMP. There were a
>handful of responses, mostly to the effect that
>- we don't know
>- we don't care
>- we get whatever the native thread library g
--On 25.08.2000 2:49 Uhr -0400 Steven W McDougall wrote:
> Now here's the trade off
>
>performanceimplementation
> preemptivehighhard
> cooperative low easy
That's by far not that easy. Actually I've often seen cooperative threading
implemented
Dan Sugalski wrote:
>
> At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote:
> >Are Perl6 threads preemptive or cooperative?
>
> Perl 6 threads will use the native threading system on each platform. To do
> otherwise means an enourmous amount of mostly useless work. It's just not
> worth it.
No
At 12:51 PM 8/25/00 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
> >
> > At 02:49 AM 8/25/00 -0400, Steven W McDougall wrote:
> > >Are Perl6 threads preemptive or cooperative?
> >
> > Perl 6 threads will use the native threading system on each platform. To do
> > otherwise means an enourmous
--On 25.08.2000 14:07 Uhr -0400 Dan Sugalski wrote:
> Perl doesn't currently run on a system that doesn't have a reasonably
> good threading library. Writing our own code would mean dedicating a few
> programmer-months to do poorly what other folks have spent quite a few
> programmer-years to do
> Writing a threads package correctly is a non-trivial thing to do.
We don't have to write a threads package.
We just have to thread the interpreter.
There's a difference.
> Perl doesn't currently run on a system that doesn't have a reasonably good
> threading library.
I abandoned an NT -> M
Cooperative threads don't support multiple CPUs very well. If the choice is
made to do cooperative threads because it is easier, another choice should be
made to at least allow independent threads to exist, that do little sharing of
data, except via the I/O system (pipes or the equivalent), so t
Steven W McDougall wrote:
>
> Thread1 Thread2
> $a = $b;$b = $a;
>
> preemptive threading requires
> - mutexes to protect $a and $b
> - a robust deadlock avoidance strategy
I think a robust deadl. avd. strat. is something like:
1: make a list of all variables
--On 25.08.2000 16:20 Uhr -0500 David L. Nicol wrote:
>
> 1: make a list of all variables referenced w/in expression
>
> 2: obtain global mutex-setting sceptre (block for this)
>
> 3: block until allowed to set mutexes on entire list in 1
>
> 4: release sceptre
>
> 5: run expression
>
> 6: releas
Markus Peter wrote:
> > 6: release all mutexes when leaving it for
> > any reason (and redoing 2 through 4 on reentry)
these reasons would include doing subroutine calls.
Which makes data loss possible, without explicit mutexes
on check points and if we've got those why bother with
implied one
> The problem is, as long as expressions can be within each other,
> and include terms that are multiple expressions, a robust deadlock
> avoidance strategy is required even with cooperative threading.
In order to understand this, we need to think in more detail about how
the Perl interpreter wor
--On 25.08.2000 20:02 Uhr -0400 Steven W McDougall wrote:
> Others have pointed out that code inside sub-expressions and blocks
> could also assign to our variables. This is true, but it isn't our
> problem. As long as each assignment is carried out correctly by the
> interpreter, then each varia
On Fri, 25 Aug 2000, David L. Nicol wrote:
> That's what I was suggesting. And if you say $a = 1 + foo() you have
> to give up your mutex on $a before calling foo(). So the programmer
> would have to work these things out with the subroutines:
I would think that you'd have already called foo()
Do separate threads
- all see the same file-scoped lexicals
- each get their own file-scoped lexicals
#!/usr/local/bin/perl
use Threads;
my $a = 0;
my $t1 = Thread->new(\&inc_a);
my $t2 = Thread->new(\&inc_a);
$t1->join;
$t2->join;
print "$a";
sub inc_a
{
$a++;
}
What should the outp
RFC1v3 says
5. Threads are a runtime construct only. Lexical scoping and
compile issues are independent of any thread boundaries. The
initial interpretation is done by a single thread. use Threads may
set up the thread constructs, but threads will not be spawned
until runtime.
15 matches
Mail list logo
