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

• Fwd: Re: [perl #133021] Removed the word "discouraged" from threads'documentation by Dave Mitchell
• Re: [perl #133021] Removed the word "discouraged" from threads'documentation by Elizabeth Mattijsen
• Re: [perl #133021] Removed the word "discouraged" from threads'documentation by Dan Book
• Re: [perl #133021] Removed the word "discouraged" from threads'documentation by Elizabeth Mattijsen
• Re: [perl #133021] Removed the word "discouraged" from threads'documentation by Dave Mitchell