Fwd: Re: [perl #133021] Removed the word "discouraged" from threads' documentation

(missed out Ccing p5p)

----- Forwarded message from Dave Mitchell <davem@iabyn.com> -----

Date: Mon, 9 Apr 2018 15:59:14 +0100
From: Dave Mitchell <davem@iabyn.com>
To: Elizabeth Mattijsen <liz@dijkmat.nl>
Subject: Re: [perl #133021] Removed the word "discouraged" from threads'
	documentation
Message-ID: <20180409145914.GN14242@iabyn.com>

On Mon, Apr 09, 2018 at 02:34:21PM +0200, Elizabeth Mattijsen wrote:
> Is that something that was fixed in the past 10 years or so?  I
> distinctly remember this only being true for *shared* arrays, which
> involve a lot of overhead.

Well, non-shared arrays can only be accessed by a single thread, so they
are not an issue.

Running the following code, which has 100 threads pushing and popping things
off a shared array shows that it ends with the same number of elements
as when it started.

    use threads;
    use threads::shared;

    my @a : shared = (1..100);

    sub inc {
        for (1..10_000) {
            push @a, $_;
            pop @a;
        }
    }

    my @t;
    push @t, threads->new(\&inc) for 1..100;
    $_->join for @t;
    printf "size=%d\n",  scalar(@a);


I've run this code on 5.10.1 and 5.27.10 and in both cases it finishes
with 100 elements.

> OOC, is this also true for hashes to which keys are being added by
> several threads?

(I don't know what OOC stands for).

If the different threads are using disjoint sets of keys when accessing
the same shared hash, they won't interfere with each other. If multiple
threads are adding, modifying and deleting the same key in a shared hash,
then of course the final result for that key in the hash will depend on
the timing; but it won't be corrupt.

> Also OOC, if multiple threads increase / decrease the reference count of
> something, is that also threadsafe by default?  AKA, will you never get
> double frees (increment missed) or DESTROY never getting called
> (decrement missed)?

The whole point of ithreads is that each thread gets its own interpreter,
with its own copy of every SV. So it's not possible for multiple threads
to access, let alone modify, the reference count of an SV. threads::shared
uses locking behind the scenes to mediate access to shared variables, so
again, ref-counting isn't an issue.

-- 
"You're so sadly neglected, and often ignored.
A poor second to Belgium, When going abroad."
    -- Monty Python, "Finland"

----- End forwarded message -----

-- 
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
    -- Bill Royston
0
davem
4/9/2018 3:00:12 PM
perl.perl5.porters 47401 articles. 0 followers. Follow

4 Replies
45 Views

Similar Articles

[PageSpeed] 43

> On 9 Apr 2018, at 17:00, Dave Mitchell <davem@iabyn.com> wrote:
> On Mon, Apr 09, 2018 at 02:34:21PM +0200, Elizabeth Mattijsen wrote:
>> Is that something that was fixed in the past 10 years or so?  I
>> distinctly remember this only being true for *shared* arrays, which
>> involve a lot of overhead.
> Well, non-shared arrays can only be accessed by a single thread, so =
they
> are not an issue.

Ah, ok, so you=E2=80=99re not talking OS-threads, but perl ithreads.

My point was about Perl code running in separate OS-threads, what I =
understand (perhaps wrongly) with things like Future.  So inside of a =
single interpreter.


I=E2=80=99m quite aware how Perl ithreads work, for the past 15 years or =
so at least:=20

    http://www.perlmonks.org/?node_id=3D288022


Liz=
0
liz
4/9/2018 4:05:06 PM
--000000000000f3e25705696d5796
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 9, 2018 at 12:05 PM, Elizabeth Mattijsen <liz@dijkmat.nl> wrote=
:

>
> > On 9 Apr 2018, at 17:00, Dave Mitchell <davem@iabyn.com> wrote:
> > On Mon, Apr 09, 2018 at 02:34:21PM +0200, Elizabeth Mattijsen wrote:
> >> Is that something that was fixed in the past 10 years or so?  I
> >> distinctly remember this only being true for *shared* arrays, which
> >> involve a lot of overhead.
> > Well, non-shared arrays can only be accessed by a single thread, so the=
y
> > are not an issue.
>
> Ah, ok, so you=E2=80=99re not talking OS-threads, but perl ithreads.
>
> My point was about Perl code running in separate OS-threads, what I
> understand (perhaps wrongly) with things like Future.  So inside of a
> single interpreter.
>
>
> I=E2=80=99m quite aware how Perl ithreads work, for the past 15 years or =
so at
> least:
>
>     http://www.perlmonks.org/?node_id=3D288022
>
>
> Liz


Future has nothing to do with threading of any sort (though it could be
leveraged in combination, such as what IO::Async::Function does on
Windows). It's a mechanism for cooperative multitasking. I'm not sure what
OS threads you are talking about that would run "inside of a single
interpreter." pthreads run outside the interpreter.

-Dan

--000000000000f3e25705696d5796
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Apr 9, 2018 at 12:05 PM, Elizabeth Mattijsen <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:liz@dijkmat.nl" target=3D"_blank">liz@dijkmat.nl</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; On 9 Apr 2018, at 17:00, Dave Mitchell &lt;<a href=3D"mailto:davem@iab=
yn.com">davem@iabyn.com</a>&gt; wrote:<br>
&gt; On Mon, Apr 09, 2018 at 02:34:21PM +0200, Elizabeth Mattijsen wrote:<b=
r>
&gt;&gt; Is that something that was fixed in the past 10 years or so?=C2=A0=
 I<br>
&gt;&gt; distinctly remember this only being true for *shared* arrays, whic=
h<br>
&gt;&gt; involve a lot of overhead.<br>
&gt; Well, non-shared arrays can only be accessed by a single thread, so th=
ey<br>
&gt; are not an issue.<br>
<br>
</span>Ah, ok, so you=E2=80=99re not talking OS-threads, but perl ithreads.=
<br>
<br>
My point was about Perl code running in separate OS-threads, what I underst=
and (perhaps wrongly) with things like Future.=C2=A0 So inside of a single =
interpreter.<br>
<br>
<br>
I=E2=80=99m quite aware how Perl ithreads work, for the past 15 years or so=
 at least:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"http://www.perlmonks.org/?node_id=3D288022" rel=3D=
"noreferrer" target=3D"_blank">http://www.perlmonks.org/?<wbr>node_id=3D288=
022</a><br>
<br>
<br>
Liz</blockquote></div><br></div><div class=3D"gmail_extra">Future has nothi=
ng to do with threading of any sort (though it could be leveraged in combin=
ation, such as what IO::Async::Function does on Windows). It&#39;s a mechan=
ism for cooperative multitasking. I&#39;m not sure what OS threads you are =
talking about that would run &quot;inside of a single interpreter.&quot; pt=
hreads run outside the interpreter.</div><div class=3D"gmail_extra"><br></d=
iv><div class=3D"gmail_extra">-Dan</div></div>

--000000000000f3e25705696d5796--
0
grinnz
4/9/2018 5:00:30 PM
> On 9 Apr 2018, at 19:00, Dan Book <grinnz@gmail.com> wrote:
> On Mon, Apr 9, 2018 at 12:05 PM, Elizabeth Mattijsen <liz@dijkmat.nl> =
wrote:
> > My point was about Perl code running in separate OS-threads, what I =
understand (perhaps
> > wrongly) with things like Future.  So inside of a single =
interpreter.
> Future has nothing to do with threading of any sort (though it could =
be leveraged in combination, such as what IO::Async::Function does on =
Windows). It's a mechanism for cooperative multitasking. I'm not sure =
what OS threads you are talking about that would run "inside of a single =
interpreter." pthreads run outside the interpreter.

Ok, so if I understand you correctly: if you run some pthreads outside =
of a Perl interpreter thread, you will never be able to run any Perl =
code in that pthreads thread that could potentially access variables =
from a Perl interpreter running in another thread?



Liz=
0
liz
4/9/2018 5:26:30 PM
On Mon, Apr 09, 2018 at 07:26:30PM +0200, Elizabeth Mattijsen wrote:
> Ok, so if I understand you correctly: if you run some pthreads outside
> of a Perl interpreter thread, you will never be able to run any Perl
> code in that pthreads thread that could potentially access variables
> from a Perl interpreter running in another thread?

I'm not sure I understand that sentence, but the basic rule of doing any
sort of threading in perl is that two OS-level threads must not
simultaneously access/modify the same perl interpreter struct (and all the
data hanging off it, e.g. SVs etc).

This was why the 5005THREADS model was abandoned. Nobody could think of a
way of avoiding all the side-effects that any trivial usage of an SV might
give rise to (e.g. changing the ref count, converting from an IV to PVIV),
without having a lock in about every second line of code in the perl
core.

I vaguely understand that the approach in Python is to have one big
central lock so only one thread can execute at any one time.

-- 
"I used to be with it, but then they changed what ‘it’ was, and now what
I’m with isn’t it. And what’s ‘it’ seems weird and scary to me."
  -- Grandpa Simpson
(It will happen to you too.)
0
davem
4/10/2018 10:50:46 AM
Reply: