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 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*
> "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.
>>
> "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>
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>
>NI> Indeed that is exactly how tied arrays work - they (automatically) add
>NI> 'p' magic (internal tie) to their elements.
>
>Hmm, I always understood a tied array to be the _array_ not each individual
>element.
The perl level tie is on the array. Th
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
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
> "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 ex
> "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
> "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, Wh
> "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 bee
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
AB> 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 don
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
> "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 wo
> 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
> > 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.
> >
> 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
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
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?
So you don't intend being able to roll back anything that has been
modified via a reference then? And if you do intend to allow th
Jarkko Hietaniemi wrote:
> Being multithreaded is not difficult, impossible, or bad as such.
> It's the make-believe that we can make all data automagically both
> shared and safe that is folly. Data sharing (also known as code
> synchronization) should be explicit; explicitly controlled by the
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 o
Alan Burlison <[EMAIL PROTECTED]> writes:
>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 en
> "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 int
(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
> Ok, I'm not super familiar with threads so bear with me, and smack me upside
> the head when need be. But if we want threads written in Perl6 to be able
> to take advantage of mulitple processors, won't we inherently have to make
> perl6 multithreaded itself (and thus multiple instances of t
ED]>
Date: Thursday, September 07, 2000 9:03 AM
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 knowin
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
> I think there may be a necessity for more than just a work area to be
> non-shared. There has been no meaningful discussion so far related to
> the fact that the vast majority of perl6 modules will *NOT* be threaded,
> but that people will want to use them in threaded programs. That is a
> non
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
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 th
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
> "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
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>> Perl will have to do atomic operations, if for no other reason than to
>> keep from core dumping and maintaining sane states.
AB> I don't see that this is necessarily true. The best suggestion I have
AB> seen so far is to have each thre
> "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 y
At 09:17 PM 9/6/00 -0400, Steven W McDougall wrote:
> > leave the locking to the coder and keep perl clean.
>
>If we don't provide this level of locking internally, then
>
> async { $a = $b }
>
>is liable to crash the interpreter.
Nope.
ilock($b);
fetch($b);
iunlock($b);
iloc
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
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 someth
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 probab
Alan Burlison <[EMAIL PROTECTED]> writes:
>
>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
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 shouldn't try to be too
>> helpful a
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/mutexe
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 t
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 mini
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
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.
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 th
> "UG" == Uri Guttman <[EMAIL PROTECTED]> writes:
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 with
> "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 ge
> what if i do $i++ and overflow into the float (or bigint) domain? that
> is enough work that you would need to have a lock around the ++. so then
> all ++ would have implied locks and their baggage. i say no atomic ops
> in perl.
>From RFC 178
[Atomic] operations typically lock their opera
> 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 documented in C and
all the functions docume
> "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> helpfu
> "CF" == Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "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 increme
> 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 an
> "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 atomi
> "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 side
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 an
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
> 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 b
> "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
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
> "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
What I'm trying to do in RFC178 is take the thread model that you get
in compiled languages like C and C++, and combine it with the Perl5
programming model in a way that makes sense.
There may be reasons not to follow RFC178 in Perl6. Maybe
- it's too hard to implement
- there are performance pr
62 matches
Mail list logo
