Re: is ||= threadsafe?
by BrowserUk (Patriarch) on Oct 25, 2010 at 02:17 UTC
|
Since this is a 'test & set',
It certainly isn't implemented using an atomic instruction, so yes. If $PageQueue is a shared variable, and the statement is part of a thread function body that may be instantiated more than once, you need to lock it before setting it.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
Re: is ||= threadsafe?
by ambrus (Abbot) on Oct 25, 2010 at 10:33 UTC
|
What's more, it can't be implemented as thread safe, because the ||= operator must evaluate its rhs only if the lhs is false, and the expression on the rhs can have any side effect, including waiting a lot, so it would be bad to lock all other threads out during that time.
| [reply] [d/l] |
|
lock $x, $x ||= $_ for long_rhs() ?
| [reply] [d/l] |
Re: is ||= threadsafe?
by ikegami (Patriarch) on Oct 25, 2010 at 03:44 UTC
|
| [reply] [d/l] |
|
But the increment doesn't happen in user code. It happens internally in the perl code, which is guaranteed to be thread safe (unless there is a bug). So this wouldn't be an issue. the issue I queried about is not, clearly, something that is internal, but is a short hand for a user-land test and then set, thus while it *could* be optimized, I sorta doubted it, but thought I'd check.
The case you are talking about would imply a bug in perl in it not being thread safe, since variable reference counts are not user-land features, but things handled automatically by perl -- so they are inherently thread-safe as much as perl is defined to be thread-safe.
That said, I'm sure you'd have to protect such increments from multi-threaded access, inside perl, but that's not something we need to worry about in userland.
| [reply] |
|
It happens internally in the perl code, which is guaranteed to be thread safe
||= happens in Perl code, yet it's not thread safe for shared variables.
You may say that's because it's the user requesting a change the variable, but that's the case for all the examples I showed too.
Now, tye and BrowserUk say the shared SV is appropriately locked internally when updated (and I believe it to be true), so that eliminates the potential problems I posited, so the point is simply that your guarantee is worthless as formulated.
That's probably because you pulled the guarantee out of this air. When I looked this up some time ago, I couldn't find any documentation on this. A very quick look still shows nothing. This is why I prompted for replies on the subject.
Update: Added everything after first line.
Update: Added "for shared variables" in response to reply.
| [reply] [d/l] |
|
|
|
|
| [reply] |
|
segmentation fault, premature deallocation and segmentation fault (respectively) are serious problems in any scenario.
| [reply] |
|
|
|
|
Admittedly, I have only waited roughly an hour for this to run, but that is sufficient for 100 threads to explore the possibilities of each your speculative modes of failure, for 100 million plus iterations each. (Ignoring all the other threaded code I've ever written that could have done so)
I consider that a pretty conclusive demonstration that you're talking out your a the top of your head.
Of course you could have tried this trivial test of your speculations yourself, in the same minimal amount of time, before posting such FUD, but that wouldn't meet your apparent motivations.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
|
Yeesh, what's with all the hostility?
See Tye's buried node for a sensible answer. Unfortunate that it wasn't posted at a more visible depth.
| [reply] |
|
|
|
|
| [reply] |
|
|