Then you are back to locking everything in sight.
Consider the simple solution.
my $group_a : shared;
my $group_b : shared;
sub foo { lock $group_a; }
sub fo1 { lock $group_a; }
sub fo2 { lock $group_a; }
sub bar { lock $group_b; }
--On 29.08.2000 12:15 Uhr -0400 Chaim Frenkel wrote:
But the grouping of related locks can most easily be done by the user
and probably a lot more efficiently then the pessimistic locking perl
would need to perform.
I completely agree. The only thing I'd have to add is that the lock
What if every subroutine tagged itself with a list of the globals
it uses, so a calling routine would know to add those to the list
of globals it wants locked?
At 12:11 PM 8/28/00 -0500, David L. Nicol wrote:
What if every subroutine tagged itself with a list of the globals
it uses, so a calling routine would know to add those to the list
of globals it wants locked?
If you're looking for automagic locking of variables, you're treading deep
into
"DLN" == David L Nicol [EMAIL PROTECTED] writes:
DLN What if every subroutine tagged itself with a list of the globals
DLN it uses, so a calling routine would know to add those to the list
DLN of globals it wants locked?
And what about all the subroutines _it_ will call? And if you solve
that
Chaim Frenkel wrote:
"DLN" == David L Nicol [EMAIL PROTECTED] writes:
DLN What if every subroutine tagged itself with a list of the globals
DLN it uses, so a calling routine would know to add those to the list
DLN of globals it wants locked?
And what about all the subroutines _it_
That a user my need to have two or more variables in sync for proper
operation. And cooperative threads don't address that issue.
Cooperative only helps _perhaps_ with perl not needing to protrect its
own structures.
We are in agreement.
I was specifically addressing the problem of
I don't understand the problem with these scenarios.
A couple of other scenerios
Thread 1Thread 2
push(@a, @b); $a[35]++
What does
User level cross variable consistancy.
mean?
push(@a, $b);
$acount++ if $b 35;
Even
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes:
SWM I don't understand the problem with these scenarios.
A couple of other scenerios
Thread 1 Thread 2
push(@a, @b);$a[35]++
Cooperative threads do not solve consistance issues. The array, its
contents
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
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.
Nonsense
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 amount
--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
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
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 gives us
This assumes that Perl6 uses the native thread
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()
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 gives
--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
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
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 ones?
20 matches
Mail list logo
