At 09:43 PM 9/9/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Right, but databases are all dealing with mainly disk access. A 1ms lock
DS operation's no big deal when it takes 100ms to fetch the data being
locked.
DS A 1ms lock operation *is* a big deal when
Chaim Frenkel wrote:
Please elaborate.
How deep do you go?
$h{a}{b}{c}{d}{e}{f}
This is my last mail on this subject - it is a half-assed idea, and this
whole thread is becoming too tedious for words. Actually, I'd extend
that to the whole p6 process. In fact I think I'll just unsubscribe.
At 04:21 PM 9/8/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS The problem with using database locking and transactions as your
DS model is that they're *expensive*. Amazingly so. The expense is
DS certainly worth it for what you get, and in many cases the
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Right, but databases are all dealing with mainly disk access. A 1ms lock
DS operation's no big deal when it takes 100ms to fetch the data being locked.
DS A 1ms lock operation *is* a big deal when it takes 100ns to fetch the data
DS being
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB Chaim Frenkel wrote:
No scanning. I was considering that all variables on a store would
safe store the previous value in a thread specific holding area[*]. Then
upon a deadlock/rollback, the changed values would be restored.
(This
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS The problem with using database locking and transactions as your
DS model is that they're *expensive*. Amazingly so. The expense is
DS certainly worth it for what you get, and in many cases the expense
DS is hidden (at least to some extent) by
Chaim Frenkel wrote:
No scanning. I was considering that all variables on a store would
safe store the previous value in a thread specific holding area[*]. Then
upon a deadlock/rollback, the changed values would be restored.
(This restoration should be valid, since the change could not
Chaim Frenkel [EMAIL PROTECTED] writes:
What tied scalar? All you can contain in an aggregate is a reference
to a tied scalar. The bucket in the aggregate is a regular bucket. No?
I tied scalar is still a scalar and can be stored in a aggregate.
Well if you want to place that restriction on
Chaim Frenkel wrote:
You aren't being clear here.
fetch($a) fetch($a)
fetch($b) ...
add ...
store($a) store($a)
Now all of the perl internals are done 'safely' but the result is garbage.
You
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB Chaim Frenkel wrote:
What tied scalar? All you can contain in an aggregate is a reference
to a tied scalar. The bucket in the aggregate is a regular bucket. No?
AB So you don't intend being able to roll back anything that has been
AB
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB Please consider carefully the potential consequences of your proposal.
I just realized, that no one has submitted a language level proposal how
deadlocks are detected, delivered to the perl program, how they are
to be recovered from, What
"r" == raptor [EMAIL PROTECTED] writes:
r ]- what if we don't use "locks", but multple versions of the same variable
r !!! What I have in mind :
r If there is transaction-based variables THEN we can use multiversioning
r mechanism like some DB - Interbase for example.
r Check here :
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI Chaim Frenkel [EMAIL PROTECTED] writes:
NI Well if you want to place that restriction on perl6 so be it but in perl5
NI I can say
NI tie $a[4],'Something';
That I didn't realize.
NI Indeed that is exactly how tied arrays work - they
At 06:18 PM 9/7/00 -0400, Chaim Frenkel wrote:
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB Chaim Frenkel wrote:
The problem I have with this plan, is reconciling the fact that a
database update does all of this and more. And how to do it is a known
problem, its been developed over
I don't even want to take things out a step to guarantee atomicity at the
statement level. There are speed issues there, since it means every
statement will need to conditionally lock everything. (Since we can't
necessarily know at compile time which variables are shared and which
aren't)
You aren't being clear here.
fetch($a) fetch($a)
fetch($b) ...
add ...
store($a) store($a)
Now all of the perl internals are done 'safely' but the result is garbage.
You don't even
Example
@a = ();
async { push @a, (1, 2, 3) };
push @a, (4, 5, 6);
print @a;
Possible output: 142536
Actually, I'm not sure I understand this.
Can someone show how to program push() on a stack machine?
- SWM
Chaim Frenkel wrote:
UG i don't see how you can do atomic ops easily. assuming interpreter
UG threads as the model, an interpreter could run in the middle of another
UG and corrupt it. most perl ops do too much work for any easy way to make
UG them atomic without explicit locks/mutexes.
Nick Ing-Simmons wrote:
Another good reason for having separate interpreter instances for each
thread is it will allow people to write non-threaded modules that can
still be safely used inside a threaded program. Let's not forget that
the overwhelming bulk of CPAN modules will probably
Nick Ing-Simmons wrote:
The tricky bit i.e. the _design_ - is to separate the op-ness from the
var-ness. I assume that there is something akin to hv_fetch_ent() which
takes a flag to say - by the way this is going to be stored ...
I'm not entirely clear on what you mean here - is it
Chaim Frenkel wrote:
I'd like to make the easy things easy. By making _all_ shared variables
require a user level lock makes the code cluttered. In some (I think)
large percentage of cases, a single variable or queue will be use to
communicate between threads. Why not make it easy for the
Chaim Frenkel wrote:
I don't see where you are differing from me.
And different interpreters doesn't completely isolate threads from each
other. You are simply giving each thread its own work/scratch area.
With the internals rewrite it may not need to be a full interpreter.
I think there
Chaim Frenkel wrote:
AB I'm sorry, but you are wrong. You are confusing transactions with
AB threading, and the two are fundamentally different. Transactions are
AB just a way of saying 'I want to see all of these changes, or none of
AB them'. You can do this even in a non-threaded
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB Chaim Frenkel wrote:
The problem I have with this plan, is reconciling the fact that a
database update does all of this and more. And how to do it is a known
problem, its been developed over and over again.
AB I'm sorry, but you are wrong.
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
AB The problem with saying that perl should ensure that the operation "$a =
AB $a + $b" is atomic is that it is an unbounded problem. When should $a
AB be automatically locked and unlocked? At the beginning and end of the
AB += op? at the
On Thu, 07 Sep 2000, Steven W McDougall wrote:
RFC 1 proposes this model, and there was some discussion of it on
perl6-language-flow.
Which is strange, since it was released for this group. Hmmm. But yes,
we did seem to hash out at least some of this before, which, to
Steven's credit, was
Subject: Re: RFC 178 (v2) Lightweight Threads
Alan Burlison [EMAIL PROTECTED] writes:
Jarkko Hietaniemi wrote:
Multithreaded programming is hard and for a given program the only
person truly knowing how to keep the data consistent and threads not
strangling each other is the programmer. Perl
Steven W McDougall [EMAIL PROTECTED] writes:
DS Some things we can guarantee to be atomic.
This is going to be tricky. A list of atomic guarentees by perl will be
needed.
From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators
Chaim Frenkel [EMAIL PROTECTED] writes:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Multithreaded programming is hard and for a given program the only
JH person truly knowing how to keep the data consistent and threads not
JH strangling each other is the programmer. Perl shouldn't
Chaim Frenkel [EMAIL PROTECTED] writes:
Some series of points (I can't remember what they are called in C)
Sequence points.
where operations are consider to have completed will have to be
defined, between these points operations will have to be atomic.
No, quite the reverse - absolutely no
Jarkko Hietaniemi wrote:
Multithreaded programming is hard and for a given program the only
person truly knowing how to keep the data consistent and threads not
strangling each other is the programmer. Perl shouldn't try to be too
helpful and get in the way. Just give user the bare
Chaim Frenkel wrote:
The problem I have with this plan, is reconciling the fact that a
database update does all of this and more. And how to do it is a known
problem, its been developed over and over again.
I'm sorry, but you are wrong. You are confusing transactions with
threading, and the
(We are not (quite) discussing what to do for Perl6 any longer. I'm
going though a learning phase here. I.e. where are my thoughts
miswired.)
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
Actually, I wasn't. I was considering the locking/deadlock handling part
of database engines. (Map row
"AB" == Alan Burlison [EMAIL PROTECTED] writes:
my $a :shared;
$a += $b;
AB If you read my suggestion carefully, you would see that I explicitly
AB covered this case and said that the internal consistency of $a would
AB always be maintained (it would have to be otherwise the interpreter
AB
At 03:02 PM 9/7/00 +0100, Nick Ing-Simmons wrote:
Alan Burlison [EMAIL PROTECTED] writes:
Jarkko Hietaniemi wrote:
Multithreaded programming is hard and for a given program the only
person truly knowing how to keep the data consistent and threads not
strangling each other is the
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Multithreaded programming is hard and for a given program the only
JH person truly knowing how to keep the data consistent and threads not
JH strangling each other is the programmer. Perl shouldn't try to be too
JH helpful and get in the
At 10:53 PM 9/5/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'd definitely rather perl not do any sort of explicit user-level
locking.
DS That's not our job, and there be dragons.
Please explain how this is possible?
What, perl not make any locks
Chaim Frenkel [EMAIL PROTECTED] writes:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'd definitely rather perl not do any sort of explicit user-level locking.
DS That's not our job, and there be dragons.
Please explain how this is possible?
Does this mean that without user specifying a
But for a single 'statement', it may be possible to gather all the
objects needing a lock and then grabbing them in order (say by address).
I still don't buy that. In Perl even simple assignments and
increments are not atomic which means that even 'single statements'
would require locking and
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH Multithreaded programming is hard and for a given program the only
JH person truly knowing how to keep the data consistent and threads not
JH strangling each other is the programmer. Perl shouldn't try to be too
JH helpful and get
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI The snag with attempting to automate such things is illustrated by :
NI thread Athread B
NI $a = $a + $b++; $b = $b + $a++;
NI So we need to 'lock' both $a and $b both sides.
NI So
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Well, there'll be safe access to individual variables when perl needs to
DS access them, but that's about it.
DS Some things we can guarantee to be atomic. The auto increment/decrement
DS operators can be reasonably guaranteed atomic, for
At 10:57 PM 9/4/00 -0400, Chaim Frenkel wrote:
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes:
PRL All threads share the same global variables
_All_ or only as requested by the user (ala :shared)?
SWM All.
Dan has gone through this with perl5 and he really would rather not
have to
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'd definitely rather perl not do any sort of explicit user-level locking.
DS That's not our job, and there be dragons.
Please explain how this is possible?
Does this mean that without user specifying a lock, perl will allow
a chaotic update
DS I'd definitely rather perl not do any sort of explicit user-level locking.
DS That's not our job, and there be dragons.
Please explain how this is possible?
Just say no...to locks.
Does this mean that without user specifying a lock, perl will allow
a chaotic update pattern to be
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Lightweight Threads
=head1 VERSION
Maintainer: Steven McDougall [EMAIL PROTECTED]
Date: 30 Aug 2000
Last Modified: 02 Sep 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 178
Status:
"PRL" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
PRL All threads see the same compiled subroutines
Why? Why not allow two different threads to have a different view of
the universe?
PRL All threads share the same global variables
_All_ or only as requested by the user (ala :shared)?
"SWM" == Steven W McDougall [EMAIL PROTECTED] writes:
PRL All threads see the same compiled subroutines
Why? Why not allow two different threads to have a different view of
the universe?
SWM 1. That's how it works in compiled languages. You have one .exe, and
SWM all threads run it.
Perl
48 matches
Mail list logo
