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
-Original Message-
From: Nick Ing-Simmons <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: Jarkko Hietaniemi <[EMAIL PROTECTED]>; Dan Sugalski <[EMAIL PROTECTED]>;
Perl6-Internals <[EMAIL PROTECTED]>; Nick Ing-Simmons
<[EMAIL PROTECTED]>
Date: Thursday, September 07, 2000
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
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> > "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>
> TH> Well if we allow value changes in the middle of iterating either
> TH> keys or values then that is a user visible behaviour change which
> TH> potential
> "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
> "TH" == Tom Hughes <[EMAIL PROTECTED]> writes:
>> The only real issue is if the change effects the iterator order. Changes
>> to values should be allowed without out any adverse effects.
TH> Well if we allow value changes in the middle of iterating either
TH> keys or values then that is a
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
On Wed, 06 Sep 2000 11:23:37 -0400, Dan Sugalski wrote:
>>Here's some high-level emulation of what it should do.
>>
>> eval {
>> my($_a, $_b, $c) = ($a, $b, $c);
>> ...
>> ($a, $b, $c) = ($_a, $_b, $_c);
>> }
>
>Nope. That doesn't ge
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
In message <[EMAIL PROTECTED]>
Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> I'd rather not have the expansion performed. Some other mechanism, either
> under the covers or perhaps even specified in the language.
Absolutely. Both mechanisms have been suggested - my under the
covers proposal
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
Dlux <[EMAIL PROTECTED]> writes:
>| I've deemed to be "too complex".) (Also note that I'm not a
>| database
>| guru, so please bear with me, and don't ask me to write the code
>| :-)
>
>Implementing threads must be done in a very clever way. It may be
>put in a shared library (m
30 matches
Mail list logo
